- Dillo-dev - lists.mailman3.com

[patch] don't restart scanning from start in Html_parse_entities ()

by jcid＠dillo.org

On Sat, Mar 15, 2008 at 08:26:32PM +0100, Johannes Hofmann wrote: > Hi, > > below is a small optinization to Html_parse_entities (). Committed. -- Cheers Jorge.-

March 17, 2008

[PATCH]: Fixing https step 1: Have a basic dpi dialog window working again

by jcid＠dillo.org

Hi Christian, On Sat, Mar 15, 2008 at 07:32:56PM +0100, Christian Kellermann wrote: > Hi Jorge, > > * Jorge Arellano Cid <jcid(a)dillo.org> [080315 18:58]: > > Sorry for the late answer, but I've had little spare time, > > and several topics to answer. > > > > Probably you have already read: > > > > http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-September/003211.ht… > > > > an got some info from there. > > Yes, thanks for the hint, it was insightful. I have spend a few > thoughts on the SSL issue and I'd like to hear your opinion on it. Funny how this makes me wonder whether you read the rest of my comment on this same email: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2008-March/003928.html :-) There I suggest for an internal implementation, but, I know it can also be done with a server dpi: http://lists.auriga.wearlab.de/pipermail/dillo-dev/2007-October/003237.html > The most work that still needs to be done is to handle certificates > and the user interaction required to make it usable. Garret wrote a good part of the certificate handling, you will find that code inside the plugin. > The user needs > to add trust values to certificates and to add or remove them > offline. I think this can fit well into a server dpi. Adding and > deleting bookmarks could be done similar to handling bookmarks. Yes. > Which might be a bit rough but is independent on fltk widgets. I > do think that we already have enough dialog types in dillo. Hard > coding the certificate handling would not make the situation any > better. That's why I implemented the dialog request option in dpip. This is, a dpi can ask dillo to pop a dialog and to send back the answer. This was working in dillo-0.8.6, and got a bit trimmed after the port. It should be simple to enable it again. > > Also I can imagine this plugin to handle client certificates which > I do believe will become a more common requirement for certain > applications in the future. Adding secure storage capabilities will > be easy. Also people will have the chance to write some "bridging" > plugin that extracts the needed data from existing storage sources > elsewhere, i.e. certificate servers,... I like the ide of an https dpi server. What I don't know is whether the current and future requisites for it to work, will make it harder to mantain in the future. At the present day both options (server and internal) look similar. > Handling this all internally means that we put functionality into > dillo that are needed for, but basically have nothing to do with > browsing. As I have grasped the spirit of this project this may not > be the way to go. A nice thing about handling https internally is > the opportunity to reuse an established connection for more than > one request, which might speed up transfers significantly. > > But on the other hand couldn't this be done by dpid for all filter > plugins? For all filter plugins, not. They were designed as one request, one answer with EOF and close as an important part of the process. OTOH, dpi servers were designed to do that. > Dpid can keep them alive as long as the following requests > belong to the same URL, then closing the connection after a timeout? > > I am sorry if this has been already decided on before. These thoughts > were rumaging aroung my head all day now... I hope these lines help. -- Cheers Jorge.-

March 17, 2008

https plugin status

by onepoint＠starurchin.org

On Sat, Mar 15, 2008 at 03:31:52PM -0400, Jorge Arellano Cid wrote: > > [Jeremey wrote] > > Getting https working would greatly reduce the number of times I > > run Firefox! > > I thought many https sites needed javascript to work. _Please_ > correct me if I'm wrong. :-) Well, I can surf my ISPs forums with dillo-fltk now that https is working. That's something! Regards, Jeremy Henty

March 17, 2008

patch: Re: [Dillo-dev] multiple-scan images consume a lot of CPU

by place＠gobigwest.com

> Your patch below works great for me. :) Here's a proper patch with proper comments. PS If anybody happens to have deep knowledge of various sorts of networking, maybe they'll know an optimal value for a BufSize test. All I know is that modem mtu is 15xx.

March 16, 2008

[patch] don't allocate tagnames on stack

by Johannes.Hofmann＠gmx.de

On Sun, Mar 16, 2008 at 10:47:07AM -0400, Jorge Arellano Cid wrote: > On Thu, Mar 13, 2008 at 09:01:37PM +0100, Johannes Hofmann wrote: > > Hi, > > > > here is another patch that avoids some malloc/free calls. > > > > I decided to completely remove tag_name, and to use Tags[tag_idx]. > Please check the patch in CVS. Cool. That's even better. > > BTW, with regard to these optimizations (which I was very fond of), > profiling showed me that the zen of speed is to attack the main bottleneck... Can you build a statically linked binary with profiling enabled? Here it does not work for some reason, so the timings in the gprof output are bogus. Only the counters work reliably. Cheers, Johannes

March 16, 2008

patch: Re: [Dillo-dev] patch: meta charset changes decoder

by Johannes.Hofmann＠gmx.de

On Sun, Mar 16, 2008 at 09:34:13AM -0400, Jorge Arellano Cid wrote: > On Thu, Mar 13, 2008 at 04:21:42PM +0000, place wrote: > > Jorge wrote: > > > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > > > This is no sort of proper fix whatsoever, but I was tired > > > > of seeing the "would set charset" message. It's actually > > > > surprisingly useful for remote files, since they're generally > > > > still at the javascript-and-css point at the end of the first packet. > > > > > > In CVS there is a new approach that restarts parsing the whole page. > > > It works with local/remote files, and page title. Please test it. > > > > In the past, I've encountered pages that go > > <head> > > <meta http-equiv="content-type" content="text/html; charset=utf-8"> > > <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> > > </head> > > > > Here's code just sticking in a flag when meta charset's been seen. > > Committed a slightly modified version. Please check. ebay.com works again for me. Thanks, Johannes

March 16, 2008

libiconv fix for OpenBSD

by jcid＠dillo.org

Hi, On Sat, Mar 15, 2008 at 12:06:17AM +0100, Christian Kellermann wrote: > * Jorge Arellano Cid <jcid(a)dillo.org> [080314 21:40]: > > > > Committed, but in two places! > > Yeah I have seen it. Why is the same code duplicated? Once should > be enough. My original patch contained such one instance of the > tests... When applying the patch, it failed (I don't know why). After a few tries I decided to patch by hand. Redundance removed, and committed. -- Cheers Jorge.-

March 16, 2008

[patch] don't allocate tagnames on stack

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 09:01:37PM +0100, Johannes Hofmann wrote: > Hi, > > here is another patch that avoids some malloc/free calls. > I decided to completely remove tag_name, and to use Tags[tag_idx]. Please check the patch in CVS. BTW, with regard to these optimizations (which I was very fond of), profiling showed me that the zen of speed is to attack the main bottleneck... -- Cheers Jorge.-

March 16, 2008

patch: Re: [Dillo-dev] patch: meta charset changes decoder

by jcid＠dillo.org

On Thu, Mar 13, 2008 at 04:21:42PM +0000, place wrote: > Jorge wrote: > > On Fri, Mar 07, 2008 at 06:17:17AM +0000, place wrote: > > > This is no sort of proper fix whatsoever, but I was tired > > > of seeing the "would set charset" message. It's actually > > > surprisingly useful for remote files, since they're generally > > > still at the javascript-and-css point at the end of the first packet. > > > > In CVS there is a new approach that restarts parsing the whole page. > > It works with local/remote files, and page title. Please test it. > > In the past, I've encountered pages that go > <head> > <meta http-equiv="content-type" content="text/html; charset=utf-8"> > <meta http-equiv="content-type" content="text/html; charset=iso-8859-1"> > </head> > > Here's code just sticking in a flag when meta charset's been seen. Committed a slightly modified version. Please check. -- Cheers Jorge.-

March 16, 2008

multiple-scan images consume a lot of CPU

by Johannes.Hofmann＠gmx.de

On Sat, Mar 15, 2008 at 11:46:59PM +0000, place wrote: > Johannes wrote: > > On Sat, Mar 15, 2008 at 10:16:09PM +0000, place wrote: > > > Johannes wrote: > > > > So as the "TODO" comment in jpeg.c already suggests, we need some > > > > way to switch off multiple-scan when the image is readily available > > > > either from cache, from disk, or from a fast network connection. > > > > > > > > I think some sort of rate limiting would be best that restricts > > > > rescans to - say - once a second. > > > That does not quite work for smaller images. The threshhold would > > need to depend somehow on the total size of the image. > > Do you encounter them much? I was hoping it was too rare to care about. Forget about this comment for now. Your patch below works great for me. I was seeing the problem for example on http://www.tourentipp.de When I went back to that page, it was pretty slow. Thanks, Johannes > > Looking at the bottom of Cache_process_queue(), maybe clients could be > taught to understand CA_Close in place of the last CA_Send for an entry. > Or some interface to get our hands on the cache entry's CA_GotData flag. > I don't know; Jorge will know better. > > > > And I get "Improper call to JPEG library in state 205" but that > > should be easily avoidable. > > Sorry, I was in a bit of a hurry at the time, and I don't have any > multiple scan jpegs now to try it on (could you point me to some?) > > It should have been something more like > > diff -pur dillo2/src/jpeg.c dillo2-cur/src/jpeg.c > --- dillo2/src/jpeg.c 2008-01-16 02:57:32.000000000 +0000 > +++ dillo2-cur/src/jpeg.c 2008-03-15 23:24:21.000000000 +0000 > @@ -293,7 +293,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > * when an image arrives slowly, but should not be used to redisplay > * cached images. > */ > - if (jpeg_has_multiple_scans(&jpeg->cinfo)) > + if ((BufSize < 2000) && jpeg_has_multiple_scans(&jpeg->cinfo)) > jpeg->cinfo.buffered_image = TRUE; > > a_Dicache_set_parms(jpeg->url, jpeg->version, jpeg->Image, > @@ -309,7 +309,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > /* decompression step 5 (see libjpeg.doc) */ > if (jpeg_start_decompress(&(jpeg->cinfo))) { > jpeg->y = 0; > - jpeg->state = jpeg_has_multiple_scans(&jpeg->cinfo) ? > + jpeg->state = jpeg->cinfo.buffered_image ? > DILLO_JPEG_READ_BEGIN_SCAN : DILLO_JPEG_READ_IN_SCAN; > } > } > @@ -355,7 +355,7 @@ static void Jpeg_write(DilloJpeg *jpeg, > > if (jpeg->y == jpeg->cinfo.image_height) { > /* end of scan */ > - if (!jpeg_has_multiple_scans(&jpeg->cinfo)) { > + if (!jpeg->cinfo.buffered_image) { > jpeg->state = DILLO_JPEG_DONE; > break; > } else { > > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)dillo.org > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev

March 16, 2008