- Dillo-dev - lists.mailman3.com

Re: [Dillo-dev] An odd request, I know...

by Jorge Arellano Cid

On Sat, 24 Jan 2004, Tom Barnes-Lawrence wrote: > Hi again, > On Mon, Jan 19, 2004 at 06:29:16PM -0300, Jorge Arellano Cid wrote: > > > Firstly, I'd like to say I've been using Dillo for over 2 years now, > > > and find it fantastic. Well, apart from a few little details (which > > > I'll probably post to the list in a couple of days, when I'm less > > > busy). So anyways, very well done for this piece of software! > > > > Thanks for your comments. A long time user, that's good news! > > Hehe, you haven't heard my complaints yet ;) Don't worry, they're > not so bad, and I'm not going to go making demands. Here you go: > > -I understand you not wanting the referer info being sent, even if > it does make the logs from my hit-counter a bit less useful, *but*, > some sites do seem to use the referer tags to work out if you're > accessing their images, etc deep-linked from some other page. > I'm afraid I can sort of sympathise with this, as the idea of > "stealing bandwidth" does have quite a lot of truth in it (it > does cost them money). > So, perhaps (as someone else suggested) Dillo could have some > button or menu option, etc that we could click to allow the > referer tags to be set temporarily for pages that need them? > Or alternatively, images on pages could automatically have the > referer tags set for them, or they could be used for accessing > *any* other file on the same server perhaps. Just thoughts. > > -It's great that the cache is used so aggressively with static > content, it keeps things very very fast, keeps the network > usage down, and is very useful when the connection goes down; > but it does seem to get used in many places where it really > shouldn't, such as dynamic content (revisit certain CGI scripts > and you just get the cache), and that problem with images- where > if a screenful of images stops loading, refreshing will *not* reload > the half-done images. > OTOH, it's *good* that dynamic content doesn't get reevaluated when > I press the *back* button. That's a PITA when other browsers do that, > as I usually just want to go back to where I was before. After considering it through the time, I believe that the problem with referer and the cache issue, can be solved using a similar technique to what we use with cookies. Unfortunately some standards allow for easy abuse of the technologies they describe. Sometimes it is the same RFC the one that warns about the problems that may arise! For instance image request with referer (as you suggest) is the basis for a spying technology widely known as web bugs. Allowing our cache to honour http cache directives blindly, would allow sites to send a refresh request on each of their advertising banners (and they usually get paid for request so this practice is very common). That's the reason why going back or forward in history is a PITA with browsers that follow them. Keeping Dillo as it is now, and allowing the user to site-tune it with regard to cookies, cache and referer is a solution that solves a broad range of problems. > > -It's probably because I'm using a snapshot of 0.8.0-pre from about > November with Frank's tabs patch (OK maybe the tabs patch doesn't > affect this), but once or twice I've found my load average go way > up, and looking at PS, found dpid spawning the https plugin > repeatedly (with each one dying again so there was only ever one > at a time). IIRC this happened (some time) after quitting Dillo. > Perhaps this is one of the things you've fixed since then. Yes, I fixed that. > -MOST important to me: Bookmarks. I like the way Dillo now has > bookmarks shown as a web page instead of a menu, I like that it allows > us to put them into categories, and I like that the DPI system allows > the bookmarks to be controlled by a separate program. > Unfortunately, bookmarks are still one of the main reasons I still > use Konqueror (despite the stupid crashes): I have lots of them, > last time I tried to work it out I calculated maybe a thousand- > and a great many of these are *not* pr0n! The only way I can cope > with so many of them is having them organised into a very deep > heirarchy. But not only does Dillo's bookmarks program not allow > this, but it has every single bookmark shown on the same page! The > scrollbar control is tiny! > So, I'd love it if the bookmarks code stuck each section in its own > page, and let me nest one section in another. Perhaps the current > version is only temporary, so you'd have time to work on other > stuff, and all this is already planned, but I thought I ought to > mention it because *this* is one thing that would really make > Dillo great for me. I'd have a go at this myself, but I've already > got lots of other things to do. OK, I suppose you do as well. Yes, I have much more to do than what I can cope with. So I sort it by priority and work on the top. As Thorben remarked, a very important point of dpis is to allow for multiple implementations of them. This is reinforced by the fact that writing a dpi doesn't require knowledge about dillo's internal working. With bookmarks, it keeps the bm list in memory, so making it to return the section list (in whatever format) and to bind each section with a page specific for it, is a one day effort. Testing it to work reliably and comfortably takes more time. If someone comes with a better implementation of bm, it may end as the default and the current one as an option. > That's it, really. For me, the problems are definitely oughtweighed > by Dillo's good points, like the stability and speed, I just want > to be able to use it a lot more! Stability!, thanks for the comment. It takes a great effort from our team to keep it stable. That's the unsexy work of chasing bugs, polishing the code, commenting, careful patch reviewing, and thoughtful design. Cheers Jorge.-

Jan. 26, 2004

Mailing list

by Jorge Arellano Cid

Hi Thorben! Is good to see you around. You've surely noticed I recently switched dillo-dev to only accept posts from its members. This is because it was receiving too much SPAM; the kind that's crafted to bypass SPAM filters. I don't know the current filtering layout of our list, but the fact is that now I receive (as the list administrator) a confirmation email for each rejected message (?) coming from a non-member. :( If the list SPAM-filters everything before checking whether it comes from a member, it's a sane default I suppose, but considering that I have near 3 confirmation requests a day (that repeat themselves for each day I leave these duties unattended), I wonder if it's possible to simply discard them. Regards Jorge.-

Jan. 26, 2004

Re: [Dillo-dev] An odd request, I know...

by Thorben Thuermer

On Sat, 24 Jan 2004 00:04:06 +0000 Tom Barnes-Lawrence <tomble(a)usermail.com> wrote: > -I understand you not wanting the referer info being sent, even if > it does make the logs from my hit-counter a bit less useful, *but*, > some sites do seem to use the referer tags to work out if you're > accessing their images, etc deep-linked from some other page. > I'm afraid I can sort of sympathise with this, as the idea of > "stealing bandwidth" does have quite a lot of truth in it (it > does cost them money). there is one important detail there that i think is very important: even if you want to avoid image linking by checking referers, you should allow EMPTY referers... that way: a) linking the images will still fail with the majority of browsers b) browsers that don't send referers will still work. c) users can for example post a link to a image on irc or whereever and the link will work (this is something that makes users like me really hate your site) d) users can use download programs to download files off the site without having to send fake referers (wget --referer, anybody?) (and to control those, there's robots.txt) imho not allowing the referer to be empty is just stupidity on the side of the people setting up the filtering, and it just makes their own problems worse, by forcing people to send fake referer headers (like my dillo does for QUITE some time now). (the patch is trivial, just add pairs of + "Referer: http://%s%s/\r\n" + URL_HOST(url), s_port->str, into src/IO/http.c (and don't get the order wrong)) > So, I'd love it if the bookmarks code stuck each section in its own > page, and let me nest one section in another. isn't this is kind of the point of seperating stuff into dpis?: if you don't like the default one, you can relatively easily change it without having to deal with the browser code or even recompile it. Greetings, Thorben Thuermer

Jan. 26, 2004

Bug on PS2 ? [was Bug meter]

by robert w hall

In article <Pine.LNX.4.58.0401251925460.10896(a)infinity.cl>, Jorge Arellano Cid <jcid(a)dillo.org> writes > > Most probably this CVS, plus a few improvements to our >configure stuff (compiling in old distros, png detection and >proper library linking) will be the basis for dillo-0.8.0-rc1. > Good news! Probably won't get round to testing for a few days, so an early warning on a more worrying recent bug... - my experience of recent cvs, compiled on the playstion2, (blackrhino 2.2.21 kernel), apparently shows a disconcerting feature. After a few minutes of scrolling up and down standard web-sites the whole system will hang (eg it's unpingable, and doesn't respond to any keyboard input), and needs a hard reset :-( Anyone else currently testing on the ps2 please (and hopefully had better experiences, or a fix)?? Bob -- robert w hall

Jan. 26, 2004

worried about dillo (cathedral and bazaar)

by linux seaq

Hi, i want to express my gratitude with the dillo developers, this is a really nice product, i use it everyday. I use mozilla only for banking, hotmail and flash sites. I'm only a user i'm not a developer, so my point of view is mainly from an user's perspective. Since dillo's win32 fork and previous discussion, it was clear to me that dillo development was, in some way, closed. That odd feeling was confirmed by the "memo" sent by main developers about patches and additions to dillo. Since that mail, all the "foreign" contributors stopped to share their improvements to dillo project.Or it seems to me at this time (PLEASE PROVE ME WRONG) That's really sad 'cause what i'm seeing right now is some kind of slowness on the development of dillo, and somehow is getting behind in needed functionality (frames,https,downloads,images, a lot of stuff out there). - from an user point of view - I recently re-read the cathedral and bazar paper, and thought to my self that dillo was heading in another direction. It seems to me that there's no intention to receive help from others, or get into account other's contributions. I believed that the main force behind a project weren't its main developers but its users and contributors. That mix made projects grow and grow. And dillo rejected that "magical" force. I'm just writing these thoughts, because as i said, i'm worried about dillo. I can't even imagine how painful would be to surf the web without it. Please everyone who loves dillo, do something so this nice project can grow without restrictions. Please don't get me wrong i don't want to start a trial, i just want dillo to evolve and get better everyday, with everyone help. Regards, Andres

Jan. 26, 2004

Re: [Dillo-dev] Bug meter

by David McKee

On Sun, 25 Jan 2004, Jorge Arellano Cid wrote: > I just commited the new (big) patch that adds a "bug meter" to > Dillo's UI. From the Changelog: > > + Added a bug-meter button that shows the count of detected HTML errors > (left click shows the errors, right click offers a validation menu). > + Removed the "show_html_warnings" option from dillorc. > + Cleaned up the code for the progressbar widgets. Very snazzy. Slashdot shows 14. Then I look I my work home page (<http://www.jlab.org/~dmckee/>) which I know is buggy because the computer center prepends a bit of junk to each file at the time it is served. I get seven errors and the details are: | +---------- HTML warning: line 5, color is not in "#RRGGBB" format HTML warning: line 15, HEAD element must go before the BODY section HTML warning: line 16, META elements must be inside the HEAD section HTML warning: line 17, META elements must be inside the HEAD section HTML warning: line 18, META elements must be inside the HEAD section HTML warning: line 19, META elements must be inside the HEAD section HTML warning: line 20, the TITLE element must be inside the HEAD section +---------- | The first one belongs to the code the CC puts in. The rest come from my (correctly formed) header: having decided that I must already be in the body, dillo gets upset when it sees header stuff... I don't know that this is worth worring about---the real problem is that the CC is knowingly serving broken code because sending good code would mean parsing each page to find the top of <body> as it is being served. Not really dillo's problem, but I thought I'd mention it. > Most probably this CVS, plus a few improvements to our > configure stuff (compiling in old distros, png detection and > proper library linking) will be the basis for dillo-0.8.0-rc1. Sounds good. > PS: I'm for letting "combat mode" rendering and https for 0.8.1 > as its been too much time without a release. Sure. The CVS has been fairly bug free and _much_ better that 0.7.3 for some time. Get a new release out, and if the rest of that stuff comes together quickly, well you just get to have a fast release schedule. -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Jan. 25, 2004

building on AIX, gcc, dillo 0.7.3

by Riccardo

Hwllo, I sent a private message, of which a reply was CC to this list AFAIK, about building dillo on my AIX system. The problem are threads. Pth can't be used and so I need the system's native threads. A solution was offered me but another email asked for more information, so I report first this information here before trying blindly. configure reports: checking target system type... rs6000-ibm-aix4.2.1.0 as far the system concerns. The error during configure is: checking whether threads work with -pthread... no. Now we will try some libraries. checking for library containing pthread_create... no configure: WARNING: *** No pthreads found. *** gcc -v yields: Reading specs from /usr/local/lib/gcc-lib/rs6000-ibm-aix4.2.1.0/2.95.3/specs gcc version 2.95.3 20010315 (release) while lslpp -l | egrep -i 'thread|xlc|gcc' bos.rte.libpthreads 4.2.1.0 COMMITTED pthreads Library xlC.cpp 3.1.4.0 COMMITTED C for AIX Preprocessor xlC.rte 3.1.4.0 COMMITTED C Set ++ for AIX Application greets, Ric

Jan. 25, 2004

Re: dillo 0.73 not compiling on slackware 3.9 ( libc5 ) (fwd)

by Jorge Arellano Cid

---------- Forwarded message ---------- Date: Sun, 25 Jan 2004 22:20:04 +0200 (EET) From: matti christensen <mchriste(a)welho.com> To: Jorge Arellano Cid <jcid(a)dillo.org> Subject: Re: dillo 0.73 not compiling on slackware 3.9 ( libc5 ) ok - said and done - and Dillo 0.73 rocks as expected ! what i would like to have is instruction of compiling the libraries myself /mc On Fri, 23 Jan 2004, Jorge Arellano Cid wrote: > > Matti, > > > > > ok - now i've recompiled x 3.3.6 with threads library installed - i also > > recompiled glib, gtk+ and dillo 0.73 - but without success - error message > > is different though; > > > > Gdk-ERROR **: Fatal IO error 11 (Try again) on X server :0.0. > > > > so - what would You suggest ?! > > Please try the pre-compiled libs I suggested. > > I will have to intall a libc5 slackware one of these days to > test this and another issues, but currently my time is devoted to > finishing the "bug-meter" feature for the soon to come 0.8.0 > release. > > Cheers > Jorge.- > > PS: Oh, by the way, sometime ago Jorgen asked me to test the > Fallback libpng detection code of a patch. Can you do that, and > get in contact with him for details? > > > > > > > reentrant ???! > > > > On Wed, 14 Jan 2004, Jorge Arellano Cid wrote: > > > > > > > > Hi Matti, > > > > > > On Tue, 13 Jan 2004, matti christensen wrote: > > > > > > > > > > > do You remember short email discussion with me; compiling Dillo 0.73 on > > > > slak 3.9 with resulting binary which did not run ( i sent an email after > > > > this one and adding threads library etc...) > > > > > > Yes I do. > > > > > > > do You think it might be possible to make Dillo run on this laptop ?! > > > > > > Absolutely! > > > > > > I was about to suggest you trying older versions of dillo to > > > find out which one is the last one to compile/run cleanly on > > > slk3.9, but I had a feel that I've seen this before: > > > > > > > Gdk-ERROR **: Fatal IO error 0 (Success) on X server :0.0. > > > > > > And then I remembered that the standard X server packages that > > > come with slk are not reentrant (thread safe), and that some time > > > ago I had to uprade it and some libs of X from a site of a nice > > > german guy that has done it. > > > > > > I don't have the link now, but for instance look at: > > > > > > http://www.linuxsavvy.com/resources/ > > > > > > There you'll find Reentrant XFree86 3.3.3 Libraries. > > > > > > You can try those, or google until finding 3.3.6 reentrant or > > > recompile them reentrant. > > > > > > > > > I Hope this helps > > > > > > Cheers > > > Jorge.- > > > > > > PS: Please let me know hot it goes. > > > > > > > > > > >

Jan. 25, 2004

Bug meter

by Jorge Arellano Cid

Hi there! I just commited the new (big) patch that adds a "bug meter" to Dillo's UI. From the Changelog: + Added a bug-meter button that shows the count of detected HTML errors (left click shows the errors, right click offers a validation menu). + Removed the "show_html_warnings" option from dillorc. + Cleaned up the code for the progressbar widgets. Most probably this CVS, plus a few improvements to our configure stuff (compiling in old distros, png detection and proper library linking) will be the basis for dillo-0.8.0-rc1. Please test it and enjoy! Cheers Jorge.- PS: I'm for letting "combat mode" rendering and https for 0.8.1 as its been too much time without a release.

Jan. 25, 2004

Re: [Dillo-dev] CPU usage

by Patrick Shanahan

* pete <opus(a)milneweb.com> [01-24-04 19:35]: > On Sat, Jan 24, 2004 at 10:57:59PM +0100, Andreas Schweitzer wrote: > > cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo login > > # just hit return here > > cvs -z3 -d:pserver:anonymous@auriga.wearlab.de:/sfhome/cvs/dillo co dillo > > # then continue with > > I am asked for a password.....and that would be?? It wont let me login anon. <enter> -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org

Jan. 25, 2004