Hi, 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! Now, my strange request: I'm currently writing a bunch of m4 macros to (statically) generate my personal website. Unfortunately, after ages of trying to come up with a decent layout that rendered properly in various browsers, I came up with pretty much nothing. But I kept seeing, every time I started Dillo, the tidy little splash screen... ...So basically, would Jorge (or whoever is responsible for that) mind if I effectively copied the HTML? I wouldn't bother to ask, as I'm just getting my macros to churn out the tags, rather than copying anybody's *content*, but I thought that might be covered by copyright anyway- in which case, I'm being extra cautious before sticking anything up on my site. Thanks in advance, Tom Barnes-Lawrence
On Sat, 17 Jan 2004, Tom Barnes-Lawrence wrote:
Hi,
Hi!
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!
Now, my strange request: I'm currently writing a bunch of m4 macros to (statically) generate my personal website. Unfortunately, after ages of trying to come up with a decent layout that rendered properly in various browsers, I came up with pretty much nothing. But I kept seeing, every time I started Dillo, the tidy little splash screen...
...So basically, would Jorge (or whoever is responsible for that) mind if I effectively copied the HTML?
Yes I do mind... I find it great if you reuse them! Go ahead.
I wouldn't bother to ask, as I'm just getting my macros to churn out the tags, rather than copying anybody's *content*, but I thought that might be covered by copyright anyway- in which case, I'm being extra cautious before sticking anything up on my site.
I'd be awful if it comes the day when those things can be patented or copyrighted. Cheers Jorge.- PS: Please let me know the URL after you finish.
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 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. -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. -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. 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!
seeing, every time I started Dillo, the tidy little splash screen...
...So basically, would Jorge (or whoever is responsible for that) mind if I effectively copied the HTML?
Yes I do mind...
I find it great if you reuse them! Go ahead.
Excellent! Thanks very much. In fact, Sunny Raspet had already offered to let me use some of his layout, but as I'd already got my macros to churn out Dillo's tags, I figured I'd wait and see instead.
I'd be awful if it comes the day when those things can be patented or copyrighted. Yeah, I know what you mean.
PS: Please let me know the URL after you finish.
It's not strictly finished, there's various pages missing, but: http://www.angelfire.com/super2/duologue/ Thanks, Tom Barnes-Lawrence
On Sat, 24 Jan 2004 00:04:06 +0000 Tom Barnes-Lawrence <tomble@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
Incidentally, I'm familiar with getting 2 copies of various emails when people reply to both me and the list... but *3*? That's just confusing. On Mon, Jan 26, 2004 at 03:08:32PM +0100, Thorben Thuermer wrote:
On Sat, 24 Jan 2004 00:04:06 +0000 Tom Barnes-Lawrence <tomble@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...
Are we considering empty referers to be the same as no 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. Probably. I have a strange image of *all* browsers ending up sending no referers in order to be able to see remotely hosted images, but I rather doubt that would happen, so you're probably right here.
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)
You hate my site? Wah! But seriously (*unless* you're meaning "your" as in "anybody's"), I know Angelfire *used* to block images on no referers, but I noticed recently that Dillo *was* showing the few images I had on my pages, and after reading your comment today, I copy-pasted the URL of my site's logo into Dillo. Showed up fine. I don't know if you just assumed that Angelfire was still doing that but you hadn't notice since you'd patched your copy of Dillo, or if you'd just thought that my site wasn't downloading all the graphics (there are only about 3 on the whole site, 5 if you count thumbnails as different to their full-size images).
d) users can use download programs to download files off the site without having to send fake referers (wget --referer, anybody?) Yeah, I'm familiar with *that*...
(and to control those, there's robots.txt) I know what robots.txt is for, how does it apply here? Are you talking about a download program that gets the *whole* site?
imho not allowing the referer to be empty is just stupidity on the side of the people setting up the filtering, and it just
Perhaps it just didn't occur to them? They want to keep their bandwidth costs down, so they'd be worrying more about that issue than supporting an obscure little niche browser like ours (even if it is lovely).
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))
Hey, that's neat, thanks! I was considering doing something like this myself (but wouldn't know where to start).
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.
Uh, yes, I know. Apart from the fact I got the impression the DPI interface was unstable (as in changing, not crashing) at the moment, I pointed out that I was quite busy right now, and wasn't sure of some of the details, either. I find working with other peoples' code fairly daunting, personally. Perhaps that's lack of experience. Tom Barnes-Lawrence
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.-
Good morning, Is there an IRC channel for Dillo at this time? And of course the next question where is it or why not? Thanks, -- Pete http://milneweb.com http://nomorevirus.com
participants (4)
-
Jorge Arellano Cid -
pete -
Thorben Thuermer -
Tom Barnes-Lawrence