August 2004 - Dillo-dev - lists.mailman3.com

[Dillo-dev]thread-safe X at fresco
by robert w hall Aug. 13, 2004

Aug. 13, 2004

The thread-safe versions of XFree3.3.3.1 have disappeared from linuxsavvy, (and my own attempts too recompile my own have produced useable, but not wholly error-free results)... But I note that vintage.fresco.org still has two earlier thread-safe Xlibs, 3.1.2 and 3.2, linked statically. Anyone used these? dillo glib gtk appear only to use libX11, libXext, (which is all the earlier fresco 3.1.2 package provides). Bob Going bravely backwards from kernel 2.6.7! -- robert w hall

2 3

[Dillo-dev]Re: Is IO.txt outdated?
by Calvin Yu Aug. 13, 2004

Aug. 13, 2004

>> It says dillo uses threads for DNS querying and reading local >> files, and signal driven I/O for TCP connections. When the socket >> gets ready for transmission, the data is sent using >> g_io_channel_write. But I can't not find the place where >> g_io_channel_write is invoked in the code. > > Yes, once upon a time it used g_io_channel_write, but not >anymore. I'll update this doc ASAP and let you know when its >ready. > >> >> In previous posts I see >> "When using threads and mutexes (pthreads), thread scheduling is >> done by a third thread or by the kernel (depends upon the >> implementation), and it is preemptive. Now, the address space may >> be shared, so the need for mutexes arise, and because of both >> reasons, performance is degraded. >> Using a pseudo-thread (CCC thread), doesn't require scheduling >> by an external process or by the kernel. All is done in the same >> process, but there's no preemption." >> But I do find a thread is spawned in "a_IO_write_chunk()". >> Would you please tell me the reason? > > Otherwise it wouldn't generate IO signals. > >> What does pseudo-thread mean? > > A non-preemptive thread as those handled by CCC. > I don't think it is really parallel. If there are several connections at the same time, one must wait until another one completes data transfer. assume such a case: one connection is responsible for downloading a big image, and other connections are going to download small images. The former one's G_IO_IN event is triggered first and it begins to download the big image. It will take long for it to complete downloading and other connections have to wait. It's unfair for them though they will cost much less time. I don't know whether I'm right. Must other connections wait until one completes or error occurs? >> Is such thread spawned in >> "a_IO_write_chunk()" pseudo-thread? > > No that one is a POSIX thread (or pthread at least ;). > >-- > Cheers > Jorge.-

2 2

[Dillo-dev]gmake error
by Opus Aug. 12, 2004

Aug. 12, 2004

Freebsd 4.10, doing CVS, gmake gives me this: gmake[3]: *** [interface.o] Error 1 gmake[3]: Leaving directory `/usr/home/petie/dillo/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/home/petie/dillo/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/home/petie/dillo' gmake: *** [all] Error 2 -- Pete http://milneweb.com http://nomorevirus.com

1 0

[Dillo-dev]urlencoding and the search dialog
by Jorge Arellano Cid Aug. 12, 2004

Aug. 12, 2004

Hi there, A patch for urlencoding what's entered in the search dialog has just been added. A couple of functions in the URL API changed its name. Everything should be OK, but further testing is welcomed. Now you can enter non safe characters in the web search dialog (mainly non ASCII) and have then automatically urlencoded in the query. The FORM submittion routines also use these functions so testing your favorite FORMS is also adviced. Cheers Jorge.-

1 0

[Dillo-dev]Is IO.txt outdaetd?
by Calvin Yu Aug. 11, 2004

Aug. 11, 2004

It says dillo uses threads for DNS querying and reading local files, and signal driven I/O for TCP connections. When the socket gets ready for transmission, the data is sent using g_io_channel_write. But I can't not find the place where g_io_channel_write is invoked in the code. In previous posts I see "When using threads and mutexes (pthreads), thread scheduling is done by a third thread or by the kernel (depends upon the implementation), and it is preemptive. Now, the address space may be shared, so the need for mutexes arise, and because of both reasons, performance is degraded. Using a pseudo-thread (CCC thread), doesn't require scheduling by an external process or by the kernel. All is done in the same process, but there's no preemption." But I do find a thread is spawned in "a_IO_write_chunk()". Would you please tell me the reason? What does pseudo-thread mean? Is such thread spawned in "a_IO_write_chunk()" pseudo-thread? Thanks a lot!

2 2

[Dillo-dev]Big Dpi patch: data stream API, and "file:" protocol as a dpi filter
by Jorge Arellano Cid Aug. 11, 2004

Aug. 11, 2004

Hi There, I've been silent for some time, working on a medium sized patch that was just commited. From the Changelog: <q> * Designed and implemented a unified API for handling data streams inside dillo plugins. Servers and filters can use it. * Converted the bookmarks server plugin to the new dpiutil API. * Moved the internal support for "file:" URIs into a dpi (filter plugin). * Added TABLE-based rendering of directory listings to the new file dpi. </q> Some time ago Jörgen sent me a crude prototype for a dpi filter for handling the "file:" URIs. The main problem was that it was very, very slow (say 10 times slower). It was all a buffering problem. At the same time I was discussing the idea of extending the API in dpiutil for https (with Garret), and also having in mind the GUI downloads dpi and maybe also turning cookies into a dpi. After a lot of thought I decided to start trying a tentative API, and ported the bookmarks server to it so the new functions could be tested better. Then I picked up the file dpi prototype and also ported it to the new API and polished it a lot. The idea behind was to test the API with different applications (i.e. different requirements) to be more confident about its design. Now it seems to be working OK, so a commit was done. Note that currently the file dpi filter is just an idea to test, it can be reversed or further improved. I want you to try it and make yourselves an impression while using it. It features two rendering modes: with <PRE> and with <TABLE>. The "%" link to the right of the "Parent" directory link makes the rendering mode switch! (it was added for testing's sake). Note that the stripes' slight contrast on the table-based mode is meant for easy reading of the file names when looking for a file by its filename. The contrast helps the eye (almost at the unconcious level) to locate the right row of it, when locating its type, size or date. The table-based mode is not rendering dotfiles at the moment. A very easy patch, I'll burden Jörgen with! :-) Bottom line: Please test it throughly and send some feedback. Cheers Jorge.- PS: Now I'll try to catch up with the latest emails and patches I was sent.

2 1

[Dillo-dev]Thanks, but keep working
by John Summerfield Aug. 9, 2004

Aug. 9, 2004

I'm glad to have found Dillo, I'd been hoping to find a light-weight browser for use on (small) servers where it's necessary to configure routers, firewalls and printers using their http interfaces. I really do not want to install Mozilla or such for these uses, they are far too enormous. I could use lynx, elinks, links or w3m, except that none of them works well either, and none has a pretty face:-). I don't mind installing a lightweight GUI desktop so as to be able to use GUI configuration tools. Dillo shows promise, but before it is useful it to me has to support 1. Basic authentication. This is essential. 2. Javascript. Some features of Billion 741GE ADSL routers require it 3. Frames. Probably not essential, but it surely will improve navigation. -- Cheers John Summerfield

1 0

[Dillo-dev]what can i do for dillo?
by Calvin Yu Aug. 6, 2004

Aug. 6, 2004

dillo-devOn Mon, Aug 02, 2004 at 07:41:33PM +0800, Calvin Yu wrote: > Dear Jorge Arellano Cid: > I'm very thankul for your advice and help. Good. > > I'm a student of colloge in China. My advicer gave me a project > of linux light-weight browser as my project for graduation. After > reviewing several open-source linux browsers, I think Dillo is a > good choice. For it is small and fast, especially fit for > embedded linux device. But there are some flaws with it. For > example, it doesn't support Chinese and JavaScript. I think these > functions are important for a browser. So I hope I can add those > functions to Dillo. As I told you before, Javascript is very complex to add. Not only the current Dw system is not ready for it, but also Javascript poses a big security threat that needs to be addressed in detail. > You told me that many persons want to make Dillo render > chinese, but they don't collaborate with you. Yes it is possbile. > I think most of them want to do such work because of their own > interest, not necessary mission. When they meet with difficulties > they will give up and disappear... I understand. > But now I have to do some work on Dillo (If I choose it as my > prototype system). I hope I can resolve those problems. Rendering chinese, alone, is more than a challenging task for a graduation project. As you know, we plan to port Dillo to FLTK, once that's done, rendering Chinese would require two things: a) Add the glyph logic module for Chinese to FLTK. b) Make sure Dillo works OK with it (FORMS, etc). You can also help us with the port to FLTK. > By the way, would you please tell me what documention should I > read if I want to do those work? I can't find enough documents on > www.dillo.org. Now I'm reading the code of Dillo. The new FAQ in our site will suggest several links (that's plenty of documentation, only for the i18n subject). Then follow the whole thread on FLTK. It shows the feasibility analysis. Please note that it's an abridgement, not all the emails we exchanged with the FLTK team are there! It was a large work. Beware that one of the worst mistakes to do in SW projects is to underestimate the complexity. My advice for you is to try Chinese rendering. That is: a) Add the glyph logic module for Chinese to FLTK. b) Make sure Dillo works OK with it (FORMS, etc). c) Help us with the port to FLTK. Cheers Jorge.-

1 0

[Dillo-dev]this page hangs dillo
by Brian Hechinger Aug. 5, 2004

Aug. 5, 2004

on my NetBSD/i386 box with dillo-current as of a couple of days ago, this following ebay page will hang dillo. does this work for anyone else? http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5712094427 -brian -- "The cats tend to administer themselves, and contrary to the expected facts, the house and everything in it was installed for their benefit." -- Nic Clews

2 1

[Dillo-dev]WebCalendar
by Peter Sinn Aug. 5, 2004

Aug. 5, 2004

WebCalendar does not display properly with Dillo 0.8.2 (Solaris 9), see: http://www.k5n.us/opensource/month.php or http://webcalendar.sourceforge.net/demo/login.php Is this a problem with Dillo or with WebCalendar? Regards, P.S.

2 1