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

Re: [Dillo-dev]Mailing list search

by Joerg Sonnenberger

On Thu, Aug 12, 2004 at 05:55:36PM -0400, Jorge Arellano Cid wrote: > J?rgen, > and everybody > > I just noticed that GMANE is forcing javascript to display > mailing list searches :(. Well, we have the relevant dillo-dev > mail folders, so maybe it's time to provide that service from our > web site. > > There surely are good programs for doing this. Does anyone know > of a good candidate? > > (the problem is: given a set of mailfolders, provide a search > engine with an HTML interface to them). Do you want a special program for this? A valid alternative would be just providing a HTML interface to the archive and use google with the site:dillo.org feature for the mailing list. That's what we are currently using for DragonFly BSD. Joerg > > -- > Cheers > Jorge.- > > _______________________________________________ > Dillo-dev mailing list > Dillo-dev(a)lists.auriga.wearlab.de > http://lists.auriga.wearlab.de/cgi-bin/mailman/listinfo/dillo-dev >

Aug. 13, 2004

Re: [Dillo-dev]Mailing list search

by Todd Slater

On Thu, Aug 12, 2004 at 05:55:36PM -0400, Jorge Arellano Cid wrote: > Jörgen, > and everybody > > I just noticed that GMANE is forcing javascript to display > mailing list searches :(. Well, we have the relevant dillo-dev > mail folders, so maybe it's time to provide that service from our > web site. > > There surely are good programs for doing this. Does anyone know > of a good candidate? > > (the problem is: given a set of mailfolders, provide a search > engine with an HTML interface to them). > > -- > Cheers > Jorge.- Jorge, I have used Namazu (http://www.namazu.org) to search Mailman archives (Pipermail) online and my maildir's locally (until I found mairix). You can plop namazu.cgi in cgi-bin to provide the web interface. I think that will do what you're looking for. I've got an example (searching pipermail archives) here: http://clevername.homeip.net/cgi-bin/namazu.cgi. There is also a MHonArc-Search, but it's been a long time since I looked at it; I didn't use it because I think it was too complicated for what I wanted. Todd

Aug. 12, 2004

[Dillo-dev]gmake error

by Opus

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

Aug. 12, 2004

[Dillo-dev]Mailing list search

by Jorge Arellano Cid

Jörgen, and everybody I just noticed that GMANE is forcing javascript to display mailing list searches :(. Well, we have the relevant dillo-dev mail folders, so maybe it's time to provide that service from our web site. There surely are good programs for doing this. Does anyone know of a good candidate? (the problem is: given a set of mailfolders, provide a search engine with an HTML interface to them). -- Cheers Jorge.-

Aug. 12, 2004

[Dillo-dev]urlencoding and the search dialog

by Jorge Arellano Cid

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.-

Aug. 12, 2004

Re: [Dillo-dev]Is IO.txt outdaetd?

by Jorge Arellano Cid

On Mon, Aug 09, 2004 at 03:18:47PM +0800, Calvin Yu wrote: > 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. Ok, I updated it. Beware that it's not an exact explanation of what happens inside Dillo today. Anyway, it continues to be an excellent source of information that describes the theory behind the code. Beware that the plugin system is not described in IO.txt and that the latest patch moved the "file:" protocol to a dpi, so it's not handled with a thread and a pipe inside Dillo anymore. Anyway, the thread and pipe pair is the basis for the generic dpi data stream transfer, so the theory in IO.txt will explain it to some extent. -- Cheers Jorge.-

Aug. 11, 2004

Re: [Dillo-dev]Big Dpi patch: data stream API, and "file:" protocol as a dpi filter

by David McKee

On Wed, 11 Aug 2004, Jorge Arellano Cid wrote: > I've been silent for some time, working on a medium sized patch > that was just commited. Seems to work...the tables mode looks pretty good. I note that if I look at dir/, follow the link to dir/subdir/, switch the rendering mode, and hit back I get dir/ in the original rendering mode, but if I look at dir/, follow the link to dir/subdir/, switch rendering modes, and follw the link to dir/subdir/../ I get the new mode. So, the back button in looking at the cached file, not calling the plugin again. Not a big deal. A refresh always gets the most recently established mode. [In the table bsed file: rendering mode:] > 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. Apple uses a similar thing in sufficiently new Finders. They use slightly more contrast, and I find that it helps more. It is, however, more visually intrusive. Cheers, -- -- David McKee -- dmckee(a)jlab.org -- (757) 269-7492 (Office)

Aug. 11, 2004

Re: [Dillo-dev]Is IO.txt outdaetd?

by Jorge Arellano Cid

On Mon, Aug 09, 2004 at 03:18:47PM +0800, Calvin Yu wrote: > 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. > Is such thread spawned in > "a_IO_write_chunk()" pseudo-thread? No that one is a POSIX thread (or pthread at least ;). -- Cheers Jorge.-

Aug. 11, 2004

[Dillo-dev]Big Dpi patch: data stream API, and "file:" protocol as a dpi filter

by Jorge Arellano Cid

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.

Aug. 11, 2004

[Dillo-dev]Thanks, but keep working

by John Summerfield

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

Aug. 9, 2004