- Dillo-dev - lists.mailman3.com

Re: mailing lists dead?

by Thorben Thuermer

On Mon, 10 Nov 2003 14:29:43 +0100 Frank de Lange <frank(a)unternet.org> wrote: > Hey PM, > > Just tried to submit a few messages to the > dillo-dev(a)lists.auriga.wearlab.de list, and got them back: > > Your message has encountered delivery problems > to the following recipient(s): > > dillo-dev(a)lists.auriga.wearlab.de > Delivery failed > 550 Unknown local part dillo-dev in <dillo-dev(a)lists.auriga.wearlab.de> a problem with the mailserver configuration... sorry, fixed > > Cheers//Frank Greetings, Thorben

Nov. 10, 2003

Re: [Dillo-dev] HTTPS Patch

by Jorge Arellano Cid

Hi, On Thu, 30 Oct 2003, Indan Zupancic wrote: > Updated the diff, gcc 2.x should work now, link is still > http://www.xs4all.nl/~dorinek/dillo/dillo-ssl.diff.gz Here go my comments. (An important part of the answer is in this email: http://article.gmane.org/gmane.comp.web.dillo.devel/1407 ) > It would be nice to get some feedback from the Dillo developers, I'd like > to know what they think should change before the code is good enough to go > into the official Dillo, and if they even consider that of course. Of course it is considered! (see above URL) > I have plenty of ideas, but most of them aren't feasible without merging > the two IOData structures (now there is one for the read part, and one for > the write part, why, I don't know, doesn't make things simpler), It serves to isolate the query process from the answer process. Also as dillo uses pipes to talk to itself, it makes sense to have read-only and write-only FDs. Of course it can be merged, but it may be not simple. > doing > that makes it much easier to do certain, more complex things that need to > have all the fd related info in one place, like ssl, connection caching > (currently Dillo opens and closes a connection for each action, although > it seems to work well, it's still more efficient to keep connections open > longer, especially with slow/bad network connections), "keep alive" (to > avoid timeout problems in ssl, quite annoying when you're taking too much > time typing an email), simple ftp support, etc. Currently dillo does that. Every time you add a bookmark, dillo and the server chat a little while before adding it (with connection caching). > I know that the Dillo developers want to implement most "extra" features > like https/ftp/bookmarks/etc as plugins, but I think it's beter to > implement the features that are used a lot, or just very important, like > https and ftp, natively in Dillo with a small implementation. The overall > code is most times smaller too, can say that Dillo is just 300 K, but it > would be a bit weird if the plugins together are bigger than Dillo after a > while. https took around 2 Kb, I think I can implement basic FTP (and > possibly ftps) in about 15 K, using no external ftp library or program > (hopefully 10, worst case 20K). That is a design decision: Monolithic vs Distributed. Is hard to have a definitive choice. Dillo follows the distributed approach. > If you let me loose on Dillo's code then this is what I would do: > > # Cleanup the IO engine, one IOData per fd. Could be. > # Moving the dns stuff to IO. > > # Move all the socket stuff into IO.c, the module that wants to handle > opening the connection should also close it (all non-internet sockets, > like files. Unix sockets may be added to IO.c.). Gzilla had a flat design, we've come a long way to layer dillo and to separate its code in modules. > # Add ftp support. It has. > # Add file upload support in html forms. Agreed. > # Add connection caching to IO. It has. > # Auto keep alive like behaviour for ssl connections. > > # Maybe always ACCEPT_SESSION for cookies when they come via a https > connection. Could be. > # Get rid of the ccc construction, or change it so that it behaves more > logical. My opinion is that you should have either a clear unique API for > each module, or one general API that is the same for each module. > Something in between like the current ccc functions is only confusing (if > you want a chain like behaviour, then use function pointer stuctures or > something). The CCC is all about parallelism and error handling. It is the supporting core of the application. Not easy to substitute. > # When changing the internal API anyway, making shared library plugins > possible too, at least for the IO part (maybe ftp library plugin as proof > of concept). Changing the internal API... > # Get rid of the splash stuff, move it to an external html file that is > opened by default when nothing else is opened. Currently the splash screen > is even opened when you do "dillo http://site.org". Loading a file is > almost as fast as the build in splash screen. Removing it makes Dillo > smaller (about 10 K), simpler and lets people make their own startup pages > (for instance a to hd saved google.com) In the past that approach was used. ~/.dillo ended having a splash file for each release. The point is that what's more memory consuming is the widget tree for rendering, not the source itself. Having a dillorc option to replace the Splash with a local file may be handy though. > As you could notice, I'm mainly interested in the internet/IO part, > graphical stuff doesn't attract me much. If it did, I would help/start > porting Dillo to FLTK. If Dillo decides to go with GTK 2 then I will > probably stop using it :(. It puzzles me: changing the IO engine, integrating parts of the code that were separated on purpose, changing the internal API, getting rid of the CCC and porting to FLTK, we'd be talking about another browser. > I don't have enough faith in GTK2, it's already > too big (and I saw the test results). If you have GTK 2 running anyway it > doesn't matter much if you run Dillo too of course, but that's the case > too with all those KDE/Gnome programs. IMHO, you should look at all the > code that a program uses, including the one in dependencies. I prefer a > program that has it's own small and efficient implementation of something > to one that is smaller but uses huge libraries. Agreed. The GTK2 issue is under study now. > I'm also thinking about making a Dillo installer (sh script) that > downloads and installs the cvs version of Dillo and applies the patches > the user wants. This needs some coordination, I saw links to other Dillo > patches, but I don't know if they are up to date, nor if the maker is > willing to keep that so. Currently the only patches I know that are up to > date are Frank's patches and my own https patch. Making a web site (or page for it) requires time, if you're willing to do that, go ahead but beware that we do not support unofficial patches so you'd have to answer all the incoming questions too. Cheers Jorge.-

Nov. 7, 2003

Re: [Dillo-dev] Simulating a slow connection

by johannes leimbach

Hi! You might try the following programs for a more genuine slow surfing experience: http://www.netlimiter.com - For Windoze http://www.monkey.org/~marius/trickle/ - For *ix, *bsd Hope that helps :)

Nov. 4, 2003

Re: [Dillo-dev] [PATCH] memory leak in dw_ext_iterator

by Frank de Lange

Jorge Arellano Cid wrote: > Is this next kbnav patch CVS-ready, or a testing version? > > I'm testing it now, fixing small things, should be CVS-ready. Cheers//Frank -- WWWWW ________________________ ## o o\ / Frank de Lange \ }# \| / +46-734352015 \ \ `--| _/ <Hacker for Hire> \ `---' \ +31-640037120 / \ frank(a)unternet.org / `------------------------' [ "Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est." ]

Nov. 4, 2003

Re: [Dillo-dev] Simulating a slow connection

by Sebastian Geerken

On Mon, Nov 03, Sebastian Geerken wrote: > At <http://www.dillo.org/download/dillo-slow-0.0.1.tar.gz>, you'll > find a dpi, which simulates a slow connection, and is useful for > testing incremental rendering. Read the README file within the tarball > for more informations. > > (I'm not yet very familiar with dpip, I just modified the "hello > world" example for my needs, and especially, currently only one > instance of this dpi can run at a time.) If you want to pass additional parameters, you have to start dillo, go to a dpi generated page (e.g. bookmarks), and then enter the dpi:/slow URL into the location bar. See Capi_verify_dpi_url_request, why: /* test POST and GET */ if (strchr(URL_STR(web->url), '?') || URL_DATA_(web->url)) { /* safety measure: only allow dpi requests from dpi-generated urls */ if (a_Nav_stack_size(web->bw)) { referer = a_History_get_url(NAV_TOP(web->bw)); if (g_strncasecmp(URL_STR(referer), "dpi:/", 5) == 0) allow = TRUE; } } else { allow = TRUE; } Although the slow page is not requsted by the bookmarks page ... Sebastian

Nov. 3, 2003

Simulating a slow connection

by Sebastian Geerken

Hi! Sorry for being silent the last week. At <http://www.dillo.org/download/dillo-slow-0.0.1.tar.gz>, you'll find a dpi, which simulates a slow connection, and is useful for testing incremental rendering. Read the README file within the tarball for more informations. (I'm not yet very familiar with dpip, I just modified the "hello world" example for my needs, and especially, currently only one instance of this dpi can run at a time.) Sebastian

Nov. 3, 2003

Re: https dpi

by Jorge Arellano Cid

On Sat, 25 Oct 2003, Madis Janson wrote: > I read the https.c included in dillo/dpi and seams, that it just > gets url and and dumps html. Yes, it's basically a dpi filter plugin. > What about content-type, cookies and POST > requests? Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? > > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Unfortunatelly I don't have definitive answers for these questions. There's more than one way to do it and the choice somewhat depends on what the underlying purpose of the bigger picture is. For instance: distributed design vs monolithic, quick implementation vs a more flexible one, low library dependencies vs linking dillo to a bigger set. Personally, I think that patching dillo with an integrated quick implementation of https (like Indan's) while we develop a more flexible dpi that provides at least the same, can be a good approach. I'll try to briefly comment your concerns: > Also, there seems to be one process for one connection, which makes hard > to implement SSL session cache. Yes, that happens with dpi filters. The idea in this case is to have an http dpi that's able to handle several connections at the same time (like the downloads dpi). That is: a dpi server instead of a dpi filter. With that scheme session cache is easy to implement. (and BTW much easier for the developer because he can arrange things much more freely than when patching inside dillo). > content-type (as above). The https dpi would need to listen the HTTP stream and so has access to the content-type sent by the remote https server. > Cookies Cookies will end being a dpi! Currently dillo enables cookies for the first instance only (this is old problem of sharing a single resource among several clients). Fortunately dpi solves this, as with the current bookmarks dpi server that can be shared by multiple running instances of dillo. When this port is done, the one-instance-only restriction for cookies will be gone. > POST POST data can be passed to the https dpi using dpip. This information is inside the DilloUrl. > Since https is http over ssl, it seems natural to use dillo's > http protocol implementation for these things (like i did with my https > proxy for dillo), but is it possible with dpi? Yes I agree with that reusing dillo's http may come handy. Now, dillo does http 1.0 only so having it done inside a dpi can also bring http 1.1 (as with wget and current https.c). The other interesting point is that the SSL/TLS library spec states that appart from making a socket secure, the details of handling the possible errors should be solved by the client application depending on the protocol and what it is being used for. So having a generic SSL/TLS gateway may look interesting but it can get tricky to implement. For intance: handshake_failure(40), bad_certificate(42), unsupported_certificate(43), certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), unknown_ca(48), are to be handled in different ways regarding what the protected protocol using SSL/TLS is, the transport circumstances and the user's choice. (ah, and all the alerts can have a "level" of fatal or not). With a gateway, having only the option of closing the connection is not enough. Question dialogs can be implemented in the gateway process itself though (a GUI inside the dpi), and you also have to take care of differentiating the protocols. With dpi, the questions and actions can be communicated to dillo with dpip or be made part of the dpi server. It provides more flexibility. Making SSL a part of IO, comes with the burden of having to develop all of this error handling knowledge inside the IO layer (making dillo grow in size and complexity). Including questions, actions a protocol differentiation. HTH Jorge.-

Nov. 3, 2003

Re: [Dillo-dev] libpng detection again...

by Andreas Schweitzer

Hi, > <current line> > CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --I_opts`" > </current line> <snip> > <candidate line> > CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --cppflags`" > </candidate line> Total approval from my side ! Yes, the two options give slightly different results, but the differences don't matter. The problem is, the png developers first introduced the --cppflags options in release 1.2.4 and in 1.2.5 they furthermore introduced --I_opts (and more fine grained flags). And dillo, of course :-), expects the latest release of libpng. So all distributions stuck at release 1.2.4 have this problem we are seeing (e.g. Suse 8.1). But moving to the more comaptible --cppflags version will fix this particular problem. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198

Nov. 3, 2003

libpng detection again...

by Jorge Arellano Cid

Hi, We've been through this several times, and today I received one more suggestion that may work: The whole point is replacing the current line in configure.in with something better ;). <current line> CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --I_opts`" </current line> Kelson and Raphael had to patch for SUSE 8.1: http://article.gmane.org/gmane.comp.web.dillo.devel/1011/match=libpng http://lists.auriga.wearlab.de/pipermail/dillo-dev/2003-April/000532.html Basically: <patched line> CPPFLAGS="$CPPFLAGS -I/usr/local/include/libpng12" </patched line> and here's the new candidate: <candidate line> CPPFLAGS="$CPPFLAGS `$PNG_CONFIG --cppflags`" </candidate line> At least it looks clean! The funny thing is that on my box, the "candidate" and "current" give different results, but it works with either one! :-) Worth a try? Surely. Please give a test to the candidate and tell us how it works for you. Cheers Jorge.-

Nov. 3, 2003

Re: [Dillo-dev] [PATCH] memory leak in dw_ext_iterator

by Jorge Arellano Cid

On Mon, 3 Nov 2003, Frank de Lange wrote: > Hi'all, > > There's a memory leak in dw_ext_iterator, which causes every call to > dw_ext_iterator_new() to leak one DwIterator. The solution is simple, as > can be seen in the attached patch. > > Jorge, can you apply this? Done! > It saves quite a bit of memory, and will do > so even more once my next kbnav patch is out (now testing). Is this next kbnav patch CVS-ready, or a testing version? > The patch > currently contains this fix for dw_ext_iterator (plus a whole lot of > other changes to it). With regard to the other changes (to dw_ext_iterator), you can consult them with Sebastian (he developed the iterators). Thxs! Jorge.-

Nov. 3, 2003