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.-