Hi, Here are some pending issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work. * Make DIV-based pages render correctly. This is the most visible rendering fault in Dillo. The textblock doesn't have a way to handle it (not implemented). IIRC I'm willing to dig into it and Johannes will help. e.g. http://www.advogato.org/faq.html * Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement. e.g. doubleclick. * Handle negative values in CSS. e.g. wikipedia. * What will we do with xhtml? To render or not to render... FF doesn't validate. BUG#732 One solution is to add a notification widget area below the control panel that hides/unhides as the find bar, to warn when a xhtml file has detected bugs (we'd also move the meta refresh warning to display here). I already have a simple patch to add xhtml rendering. The widget implemetation is the missing part. It should be much simpler than the close button in each tab. :-) e.g. http://planet.postgresql.org/ * Jump to #anchor doesn't work correctly. It looks like a timing issue, but the idle-call API needs a review as a whole. * dpi for "view page source" (it re-uses search capability). This requires a check of the current data-passing inside DPIP. * Improve the DPI development/debug framework. * https dialog bombing issue. BUG#868 AKA make https dpi a server (i.e. not a filter dpi). * Render bug at http://www.directfb.org/ (and its links). The table has too wide a first column. Back/Fwd solves it. * handling in fltk.org The relevant point is to define a consistent way to handle whitespace in the textblock. * FTP download doesn't work?! -- Cheers Jorge.-
Jorge wrote:
* Render bug at http://www.directfb.org/ (and its links). The table has too wide a first column. Back/Fwd solves it.
I generally run dillo with my nowrap patch, which isn't showing this problem. (But before I make it sound perfect, I have noticed insufficiently wide menu widgets for SELECT on first load on occasion lately, but haven't yet gotten around to looking into whether it's the patch's fault)
* handling in fltk.org The relevant point is to define a consistent way to handle whitespace in the textblock.
What is wrong here? The wide underlines?
* FTP download doesn't work?!
I haven't been having trouble with FTP. PS I see that there's a new fltk2 out that may be worth upgrading to (scandir glibc thing) so that we can find out whether to recommend it on the download page.
Hi, On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote:
Hi,
Here are some pending issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work.
* Make DIV-based pages render correctly. This is the most visible rendering fault in Dillo. The textblock doesn't have a way to handle it (not implemented). IIRC I'm willing to dig into it and Johannes will help. e.g. http://www.advogato.org/faq.html
With DIV-based pages you mean floats as in http://www.w3.org/TR/CSS21/visuren.html#floats? Yes, this is the most obvious rendering problem atm.
* Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement. e.g. doubleclick.
* Handle negative values in CSS. e.g. wikipedia.
Actually it's dw/* that needs to be adapted to handle negative margins. This might be related to the floats stuff.
* What will we do with xhtml? To render or not to render... FF doesn't validate. BUG#732 One solution is to add a notification widget area below the control panel that hides/unhides as the find bar, to warn when a xhtml file has detected bugs (we'd also move the meta refresh warning to display here). I already have a simple patch to add xhtml rendering. The widget implemetation is the missing part. It should be much simpler than the close button in each tab. :-) e.g. http://planet.postgresql.org/
* Jump to #anchor doesn't work correctly. It looks like a timing issue, but the idle-call API needs a review as a whole.
* dpi for "view page source" (it re-uses search capability). This requires a check of the current data-passing inside DPIP.
* Improve the DPI development/debug framework.
* https dialog bombing issue. BUG#868 AKA make https dpi a server (i.e. not a filter dpi).
* Render bug at http://www.directfb.org/ (and its links). The table has too wide a first column. Back/Fwd solves it.
Yes, I've seen this on several pages.
* handling in fltk.org The relevant point is to define a consistent way to handle whitespace in the textblock.
Can you explain the problem a bit?
* FTP download doesn't work?!
wget - based downloads work mostly fine for me. Where do you see an issue? I've got one more point: * Add clipping to the fltk drawing code, so that e.g. margins of huge boxes don't cause X11 coordinate overflows. E.g. on http://alpen-panoramen.de/newcomments.php I will try to fix that. Similar issues occur with very long lines in plain.cc. Cheers, Johannes
On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote:
Hi,
On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote:
Hi,
Here are some pending issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work.
* Make DIV-based pages render correctly. This is the most visible rendering fault in Dillo. The textblock doesn't have a way to handle it (not implemented). IIRC I'm willing to dig into it and Johannes will help. e.g. http://www.advogato.org/faq.html
With DIV-based pages you mean floats as in http://www.w3.org/TR/CSS21/visuren.html#floats?
Exactly.
Yes, this is the most obvious rendering problem atm.
It looks complex, and it will take some time to study before coming with implementation ideas.
* Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement. e.g. doubleclick.
* Handle negative values in CSS. e.g. wikipedia.
Actually it's dw/* that needs to be adapted to handle negative margins. This might be related to the floats stuff.
It looks like. Maybe they can be implemented separately.
* Add clipping to the fltk drawing code, so that e.g. margins of huge boxes don't cause X11 coordinate overflows. E.g. on http://alpen-panoramen.de/newcomments.php I will try to fix that. Similar issues occur with very long lines in plain.cc.
At what priority? -- Cheers Jorge.-
On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote:
Hi,
On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote:
Hi,
Here are some pending issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work.
* Make DIV-based pages render correctly. This is the most visible rendering fault in Dillo. The textblock doesn't have a way to handle it (not implemented). IIRC I'm willing to dig into it and Johannes will help. e.g. http://www.advogato.org/faq.html
With DIV-based pages you mean floats as in http://www.w3.org/TR/CSS21/visuren.html#floats? Yes, this is the most obvious rendering problem atm.
* Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement. e.g. doubleclick.
* Handle negative values in CSS. e.g. wikipedia.
Actually it's dw/* that needs to be adapted to handle negative margins. This might be related to the floats stuff.
* What will we do with xhtml? To render or not to render... FF doesn't validate. BUG#732 One solution is to add a notification widget area below the control panel that hides/unhides as the find bar, to warn when a xhtml file has detected bugs (we'd also move the meta refresh warning to display here). I already have a simple patch to add xhtml rendering. The widget implemetation is the missing part. It should be much simpler than the close button in each tab. :-) e.g. http://planet.postgresql.org/
* Jump to #anchor doesn't work correctly. It looks like a timing issue, but the idle-call API needs a review as a whole.
* dpi for "view page source" (it re-uses search capability). This requires a check of the current data-passing inside DPIP.
* Improve the DPI development/debug framework.
* https dialog bombing issue. BUG#868 AKA make https dpi a server (i.e. not a filter dpi).
* Render bug at http://www.directfb.org/ (and its links). The table has too wide a first column. Back/Fwd solves it.
Yes, I've seen this on several pages.
* handling in fltk.org The relevant point is to define a consistent way to handle whitespace in the textblock.
Can you explain the problem a bit?
* FTP download doesn't work?!
wget - based downloads work mostly fine for me. Where do you see an issue?
I've got one more point:
* Add clipping to the fltk drawing code, so that e.g. margins of huge boxes don't cause X11 coordinate overflows. E.g. on http://alpen-panoramen.de/newcomments.php I will try to fix that.
Ok fix committed. This took a lot longer than expected. I almost had full polygon clipping implemented which is quite complex, until I realized that it is much simpler to change Style::drawBorder() to use rectangles and triangles instead of a single polygon for each side. That way we can easily clip the large part of the border (the rectangle) and avoid X11 coordinate overflows. It also seems that this makes dillo a bit snappier. Cheers, Johannes
On Tue, Sep 01, 2009 at 09:30:54PM +0200, Johannes Hofmann wrote:
On Fri, Jul 24, 2009 at 07:19:43PM +0200, Johannes Hofmann wrote:
Hi,
On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote:
Hi,
Here are some pending issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work.
* Make DIV-based pages render correctly. This is the most visible rendering fault in Dillo. The textblock doesn't have a way to handle it (not implemented). IIRC I'm willing to dig into it and Johannes will help. e.g. http://www.advogato.org/faq.html
With DIV-based pages you mean floats as in http://www.w3.org/TR/CSS21/visuren.html#floats? Yes, this is the most obvious rendering problem atm.
* Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement. e.g. doubleclick.
* Handle negative values in CSS. e.g. wikipedia.
Actually it's dw/* that needs to be adapted to handle negative margins. This might be related to the floats stuff.
* What will we do with xhtml? To render or not to render... FF doesn't validate. BUG#732 One solution is to add a notification widget area below the control panel that hides/unhides as the find bar, to warn when a xhtml file has detected bugs (we'd also move the meta refresh warning to display here). I already have a simple patch to add xhtml rendering. The widget implemetation is the missing part. It should be much simpler than the close button in each tab. :-) e.g. http://planet.postgresql.org/
* Jump to #anchor doesn't work correctly. It looks like a timing issue, but the idle-call API needs a review as a whole.
* dpi for "view page source" (it re-uses search capability). This requires a check of the current data-passing inside DPIP.
* Improve the DPI development/debug framework.
* https dialog bombing issue. BUG#868 AKA make https dpi a server (i.e. not a filter dpi).
* Render bug at http://www.directfb.org/ (and its links). The table has too wide a first column. Back/Fwd solves it.
Yes, I've seen this on several pages.
* handling in fltk.org The relevant point is to define a consistent way to handle whitespace in the textblock.
Can you explain the problem a bit?
* FTP download doesn't work?!
wget - based downloads work mostly fine for me. Where do you see an issue?
I've got one more point:
* Add clipping to the fltk drawing code, so that e.g. margins of huge boxes don't cause X11 coordinate overflows. E.g. on http://alpen-panoramen.de/newcomments.php I will try to fix that.
Ok fix committed. This took a lot longer than expected. I almost had full polygon clipping implemented which is quite complex, until I realized that it is much simpler to change Style::drawBorder() to use rectangles and triangles instead of a single polygon for each side. That way we can easily clip the large part of the border (the rectangle) and avoid X11 coordinate overflows. It also seems that this makes dillo a bit snappier.
Good, I also feel the extra snappiness! -- Cheers Jorge.-
On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote:
* Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement.
I'd be very careful with that assumptions. A good regex engine needs a single pass over the input string independent of the number of strings to search for. Note that the OS regex might not work that well, but e.g. TRE isn't that big. Joerg
On Fri, Jul 24, 2009 at 07:51:46PM +0200, Joerg Sonnenberger wrote:
On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote:
* Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement.
I'd be very careful with that assumptions. A good regex engine needs a single pass over the input string independent of the number of strings to search for. Note that the OS regex might not work that well, but e.g. TRE isn't that big.
Yes, here is a nice article about regexp matching: http://swtch.com/~rsc/regexp/regexp1.html IRC corvid already did some testing with regexps for adblocking. Cheers, Johannes
Johannes wrote:
On Fri, Jul 24, 2009 at 07:51:46PM +0200, Joerg Sonnenberger wrote:
On Fri, Jul 24, 2009 at 11:33:28AM -0400, Jorge Arellano Cid wrote:
* Add blocker (this also has to do with privacy). A full RE-based one may have significant overhead (test required), but simple string-matching may do most of the trick. I've also thought for a long time that a "don't load from other sites" preference may help a lot. The whole topic needs some thought but it's not hard to implement.
I'd be very careful with that assumptions. A good regex engine needs a single pass over the input string independent of the number of strings to search for. Note that the OS regex might not work that well, but e.g. TRE isn't that big.
Yes, here is a nice article about regexp matching: http://swtch.com/~rsc/regexp/regexp1.html
IRC corvid already did some testing with regexps for adblocking.
So far as I can recall, - using a small number of rules and some fnmatch() didn't give any obvious slowdown, although I didn't gprof it. - trying to make one big rule naively for regexec() used a huge amount of memory. and that's as far as I got.
Jorge wrote:
* Jump to #anchor doesn't work correctly. It looks like a timing issue, but the idle-call API needs a review as a whole.
Speaking of idle, is there a reasonable way to make it so that the importance goes 1) network->cache 2) UI responsive 3) cache->textblock I know we have "throttle rendering" listed in the plans, but I seem to recall that being a KB/s sort of thing.
On Sun, Jul 26, 2009 at 05:21:07PM +0000, corvid wrote:
Jorge wrote:
* Jump to #anchor doesn't work correctly. It looks like a timing issue, but the idle-call API needs a review as a whole.
Speaking of idle, is there a reasonable way to make it so that the importance goes 1) network->cache 2) UI responsive 3) cache->textblock
Given the way the code and network engine are designed, there're much simpler ways to achieve UI responsiveness. For instance: AFAIR, currently the redraw requests are queued and idled. When the idle queue is finally processed all the pending redraws are issued one after another. Considering that rendering is a resource-heavy operation, if the drawing code could cancel the previous requests and only issue the really needed ones this alone could reduce CPU usage by a significative factor, and make the whole browser feel much faster.
I know we have "throttle rendering" listed in the plans, but I seem to recall that being a KB/s sort of thing.
There're several ways to approach this problem... -- Cheers Jorge.-
Jorge wrote:
On Sun, Jul 26, 2009 at 05:21:07PM +0000, corvid wrote:
Jorge wrote:
* Jump to #anchor doesn't work correctly. It looks like a timing issue, but the idle-call API needs a review as a whole.
Speaking of idle, is there a reasonable way to make it so that the importance goes 1) network->cache 2) UI responsive 3) cache->textblock
Given the way the code and network engine are designed, there're much simpler ways to achieve UI responsiveness.
For instance: AFAIR, currently the redraw requests are queued and idled. When the idle queue is finally processed all the pending redraws are issued one after another. Considering that rendering is a resource-heavy operation, if the drawing code could cancel the previous requests and only issue the really needed ones this alone could reduce CPU usage by a significative factor, and make the whole browser feel much faster.
Ohh... I thought it was doing this already.
--- On Fri, 7/24/09, Jorge Arellano Cid <jcid@dillo.org> wrote:
From: Jorge Arellano Cid <jcid@dillo.org> Subject: [Dillo-dev] Planning To: "Dillo mailing list" <dillo-dev@dillo.org> Date: Friday, July 24, 2009, 11:33 AM Hi,
? Here? are? some? pending? issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work.
* Add blocker (this also has to do with privacy). ???A? full? RE-based? one? may? have? significant? overhead (test required),? but? simple string-matching may do most of the trick. I've? also? thought? for? a? long? time? that? a "don't load from other? sites"? preference? may? help a lot. The whole topic needs some thought but it's not hard to implement. ???e.g. doubleclick.
Or you could just point users to privoxy, junkbuster, WWWOFFLE, and/or polipo. I don't see any mention of a limit on concurrent connections that was proposed earlier, and as far as I know it hasn't been implemented. In addition to the reasons given earlier, it is very frustrating to have to implement your own traffic-shaping just to avoid being blocked by a rate/connection-limiting firewall, or to avoid being blocklisted by a site you had hoped to visit. I'd hate to see dillo gain a reputation as a problematic UserAgent, and perhaps be blocked by some heavy-handed administrators. b.
On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote:
--- On Fri, 7/24/09, Jorge Arellano Cid <jcid@dillo.org> wrote:
From: Jorge Arellano Cid <jcid@dillo.org> Subject: [Dillo-dev] Planning To: "Dillo mailing list" <dillo-dev@dillo.org> Date: Friday, July 24, 2009, 11:33 AM Hi,
? Here? are? some? pending? issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work.
* Add blocker (this also has to do with privacy). ???A? full? RE-based? one? may? have? significant? overhead (test required),? but? simple string-matching may do most of the trick. I've? also? thought? for? a? long? time? that? a "don't load from other? sites"? preference? may? help a lot. The whole topic needs some thought but it's not hard to implement. ???e.g. doubleclick.
Or you could just point users to privoxy, junkbuster, WWWOFFLE, and/or polipo.
I don't see any mention of a limit on concurrent connections that was proposed earlier, and as far as I know it hasn't been implemented. In addition to the reasons given earlier, it is very frustrating to have to implement your own traffic-shaping just to avoid being blocked by a rate/connection-limiting firewall, or to avoid being blocklisted by a site you had hoped to visit. I'd hate to see dillo gain a reputation as a problematic UserAgent, and perhaps be blocked by some heavy-handed administrators.
That was an incomplete list to start sorting priorities. * Limit number of concurrent connections. is certainly a valid item, also as is * Document CCC, dlib and dillo in doxygen format. Please Johannes or corvid, sort the titles of the items we have so far in this thread so we can sort them and do our planning. -- Cheers Jorge.-
On Wed, Jul 29, 2009 at 02:14:30PM -0400, Jorge Arellano Cid wrote:
[...] That was an incomplete list to start sorting priorities.
BTW, we haven't even mentioned the javascript prototype, which is certainly a major topic. This mainly because it needs a lot of thought, a decision on whether to do it through dpip, etc. We'd be in a better shape to decide on scripting once the floats are in place, and some of the related topics are solved. -- Cheers Jorge.-
Jorge wrote:
On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote:
--- On Fri, 7/24/09, Jorge Arellano Cid <jcid@dillo.org> wrote:
From: Jorge Arellano Cid <jcid@dillo.org> Subject: [Dillo-dev] Planning To: "Dillo mailing list" <dillo-dev@dillo.org> Date: Friday, July 24, 2009, 11:33 AM Hi,
? Here? are? some? pending? issues which I've partially sorted by priority (at least the top half). Please add the missing ones and let's try to finish sorting it, with a view to planify our work.
* Add blocker (this also has to do with privacy). ???A? full? RE-based? one? may? have? significant? overhead (test required),? but? simple string-matching may do most of the trick. I've? also? thought? for? a? long? time? that? a "don't load from other? sites"? preference? may? help a lot. The whole topic needs some thought but it's not hard to implement. ???e.g. doubleclick.
Or you could just point users to privoxy, junkbuster, WWWOFFLE, and/or polipo.
Perhaps so. I would like some way to make it so that dillo would always ask me before following redirections, but maybe I should just argue for a pref for that specific thing rather than going for a whole general adblockerplus deal.
I don't see any mention of a limit on concurrent connections that was proposed earlier, and as far as I know it hasn't been implemented. In addition to the reasons given earlier, it is very frustrating to have to implement your own traffic-shaping just to avoid being blocked by a rate/connection-limiting firewall, or to avoid being blocklisted by a site you had hoped to visit. I'd hate to see dillo gain a reputation as a problematic UserAgent, and perhaps be blocked by some heavy-handed administrators.
If I had magical make-Jorge-do-my-bidding powers, this would be on the top of my list.
* Document CCC, dlib and dillo in doxygen format.
The situation seems to me as follows: pre-doxygen: easy-to-read code, useless documentation post-doxygen: hard-to-read code, useless documentation
Please Johannes or corvid, sort the titles of the items we have so far in this thread so we can sort them and do our planning.
I guess I'll paw through it and stuff everything into Plans.html.
On Thu, Jul 30, 2009 at 02:13:52AM +0000, corvid wrote:
Jorge wrote:
On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote:
--- On Fri, 7/24/09, Jorge Arellano Cid <jcid@dillo.org> wrote: I don't see any mention of a limit on concurrent connections that was proposed earlier, and as far as I know it hasn't been implemented. In addition to the reasons given earlier, it is very frustrating to have to implement your own traffic-shaping just to avoid being blocked by a rate/connection-limiting firewall, or to avoid being blocklisted by a site you had hoped to visit. I'd hate to see dillo gain a reputation as a problematic UserAgent, and perhaps be blocked by some heavy-handed administrators.
If I had magical make-Jorge-do-my-bidding powers, this would be on the top of my list.
Interesting... I'll give it a look, try to come up with raw patch and send it to you for polish. Would you?
* Document CCC, dlib and dillo in doxygen format.
The situation seems to me as follows: pre-doxygen: easy-to-read code, useless documentation post-doxygen: hard-to-read code, useless documentation
Oh, sounds harsh! For me Dw docs have been a bless. Without them I would not be able to rewrite the table-formating algorithms. Non-dw documents under doc/ are outdated and I have to agree they are of little use. I'll try to write one about CCC that will hopefully help you with the limit on concurrent connections. -- Cheers Jorge.-
On Thu, Jul 30, 2009 at 07:55:43PM -0400, Jorge Arellano Cid wrote:
On Thu, Jul 30, 2009 at 02:13:52AM +0000, corvid wrote:
Jorge wrote:
On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote:
--- On Fri, 7/24/09, Jorge Arellano Cid <jcid@dillo.org> wrote: I don't see any mention of a limit on concurrent connections that was proposed earlier, and as far as I know it hasn't been implemented. In addition to the reasons given earlier, it is very frustrating to have to implement your own traffic-shaping just to avoid being blocked by a rate/connection-limiting firewall, or to avoid being blocklisted by a site you had hoped to visit. I'd hate to see dillo gain a reputation as a problematic UserAgent, and perhaps be blocked by some heavy-handed administrators.
If I had magical make-Jorge-do-my-bidding powers, this would be on the top of my list.
Interesting...
I'll give it a look, try to come up with raw patch and send it to you for polish. Would you?
* Document CCC, dlib and dillo in doxygen format.
The situation seems to me as follows: pre-doxygen: easy-to-read code, useless documentation post-doxygen: hard-to-read code, useless documentation
Oh, sounds harsh!
Yes that's a bit harsh, but I think corvid is right to some degree. doxygen style comments that describe every method and their parameters are not needed in dillo. It is no library after all. What is really important is an up-to-date overview document that explains the concepts. The rest can mostly be figured out from the code.
For me Dw docs have been a bless. Without them I would not be able to rewrite the table-formating algorithms.
Yes. the dw/* documentation is good because it describes the concepts. But if I want to find out what some method does, I now look at the code, not the docs.
Non-dw documents under doc/ are outdated and I have to agree they are of little use. I'll try to write one about CCC that will hopefully help you with the limit on concurrent connections.
That would be great. Cheers, Johannes
On Fri, Jul 31, 2009 at 07:40:20AM +0200, Johannes Hofmann wrote:
On Thu, Jul 30, 2009 at 07:55:43PM -0400, Jorge Arellano Cid wrote:
On Thu, Jul 30, 2009 at 02:13:52AM +0000, corvid wrote:
Jorge wrote:
On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote:
--- On Fri, 7/24/09, Jorge Arellano Cid <jcid@dillo.org> wrote: I don't see any mention of a limit on concurrent connections that was proposed earlier, and as far as I know it hasn't been implemented. In addition to the reasons given earlier, it is very frustrating to have to implement your own traffic-shaping just to avoid being blocked by a rate/connection-limiting firewall, or to avoid being blocklisted by a site you had hoped to visit. I'd hate to see dillo gain a reputation as a problematic UserAgent, and perhaps be blocked by some heavy-handed administrators.
If I had magical make-Jorge-do-my-bidding powers, this would be on the top of my list.
Interesting...
I'll give it a look, try to come up with raw patch and send it to you for polish. Would you?
* Document CCC, dlib and dillo in doxygen format.
The situation seems to me as follows: pre-doxygen: easy-to-read code, useless documentation post-doxygen: hard-to-read code, useless documentation
Oh, sounds harsh!
Yes that's a bit harsh, but I think corvid is right to some degree. doxygen style comments that describe every method and their parameters are not needed in dillo. It is no library after all. What is really important is an up-to-date overview document that explains the concepts. The rest can mostly be figured out from the code.
For me Dw docs have been a bless. Without them I would not be able to rewrite the table-formating algorithms.
Yes. the dw/* documentation is good because it describes the concepts. But if I want to find out what some method does, I now look at the code, not the docs.
FWIW, when I said "doxygen format" I meant something similar to dw. As you remark, the concepts are the important part. The functions are well commented in the code. I don't know whether there's a fixed doxygen standard, and surely didn't mean it. Sorry for the confusion. -- Cheers Jorge.-
Jorge wrote:
On Thu, Jul 30, 2009 at 02:13:52AM +0000, corvid wrote:
Jorge wrote:
On Tue, Jul 28, 2009 at 10:01:12PM -0700, bf wrote:
--- On Fri, 7/24/09, Jorge Arellano Cid <jcid@dillo.org> wrote: I don't see any mention of a limit on concurrent connections that was proposed earlier, and as far as I know it hasn't been implemented. In addition to the reasons given earlier, it is very frustrating to have to implement your own traffic-shaping just to avoid being blocked by a rate/connection-limiting firewall, or to avoid being blocklisted by a site you had hoped to visit. I'd hate to see dillo gain a reputation as a problematic UserAgent, and perhaps be blocked by some heavy-handed administrators.
If I had magical make-Jorge-do-my-bidding powers, this would be on the top of my list.
Interesting...
I'll give it a look, try to come up with raw patch and send it to you for polish. Would you?
I can try. It would be nice if we could have Keep-Alive. (Conceivably pipelining someday, but there might be too many annoying failure modes to recover from.)
* Document CCC, dlib and dillo in doxygen format.
The situation seems to me as follows: pre-doxygen: easy-to-read code, useless documentation post-doxygen: hard-to-read code, useless documentation
Oh, sounds harsh!
For me Dw docs have been a bless. Without them I would not be able to rewrite the table-formating algorithms.
The conceptual dw docs (doc/*.doc) have helped me understand some things at times (but not due to their doxygenicity), but the doxygen stuff in the source makes it harder for me to read comments.
Non-dw documents under doc/ are outdated and I have to agree they are of little use. I'll try to write one about CCC that will hopefully help you with the limit on concurrent connections.
Yeah, I should dig through some of doc/*.txt and update some things in the areas I'm familiar with.
participants (5)
-
bf2006a＠yahoo.com -
corvid＠lavabit.com -
jcid＠dillo.org -
joerg.sonnenberger＠web.de -
Johannes.Hofmann＠gmx.de