Andreas, Here go my comments...
On Tue, Aug 19, 2003 at 12:33:53AM +0200, Andreas Schweitzer wrote:
Hi,
All right, I did it. I made my first dpi ! :-) (heavily That's great, I hope to make a new patch for dpid available soon.
Good! That means it's understandable now! :-)
The second caveat : dillo does not automatically call this plugin upon such a URL. It is easy to patch dillo, though.
Creating a new dpi still requires more effort than it should.
Eventually there'll be a mechanism for automating the inclusion of new URL-handling plugins. We're working on it with Ferdi.
However, this brings me to my questions : 1) will there be a generic URL->dpi mapping ? I could imagine that dpid could actually handle that. Yes, but I think you mean URL->SERVICE, a dpi is just an implementation of a service.
Ditto!. The distinction is relevant because there may be several different dpi programs that implement the same service. The user makes a choice and uses _one_ of them.
I think, one would need to only modify IO/Url.c and capi.c to simply pass through EVERYTHING to the dpi framework. However, some "core URL handling dpi's" that will become part of the dillo package can probably stay hardcoded in dillo.
And attached to a service name... If there's a dpi for handling it, no problem. If not, warn that is not an available service.
1b) Either way, I am planing on writing a "catch-all-URL handler" or "fallback handler" or "univeral URL handler" or the like. It will give the user the possibility to start an external program for handling certain URL's. In fact, with my current dpi, this is quite easy to do :-).
OK, but I think we should hold off on 1 and 1b until I make the next dpid patch available.
Me too.
2) Does it make sense to write a library for all the dpi's ? I, for myself, did start simply collecting all the functions that I found in dpi/ and are used by many dpi's and put them in a library. Like the various send_stream functions or the get_attr_value function, or the encoding and decoding functions. Yes, that would be very useful. Your strategy of creating a library of functions which are actually used by many dpis is a good one.
3) About configuration (and I think I read comments about this in the code), shouldn't there be only one config file ? and not dpidrc and possibly different configs for all the dpis ? maybe even merge cookiesrc with dillorc ? Yes, my next dpid patch gets rid of dpidrc.
This is the only point I have some doubts. I've always thought that it is a good idea to keep separate configuration files for dillo, and its dpis (and dpid). One file with a lengthy collection of not tightly-related configuration directives sounds to me as low-cohesion and high-coupling (I'm not sure about what are the words in english for those technical terms. In spanish it is: cohesión y acoplamiento). The idea of having a preferences plugin providing an HTML GUI for: dillo, dpid, and each dpi, is what I picture in the long term. Something like: .-------. | Dillo | Dpid | ftp | https | .... | ---------------------------------------------------. | | | <dillo's preferences here> | | ... | | '-----------------------------------------------------------' Restore Apply Save I think that is easier and cleaner with separate configuration files. Also, the rc for each dpi would be located in its own dpi directory tree (available in next dpid patch). Note that the task of the preferences dpi is to change the rc file providing a nice GUI, not to make the changes effective. Taking the changes into account is a thing that each program knows better. The preferences dpi will "tell" that program to reread the rc and update its state, probably through dpidc or dpip.
I guess some of this (or all of it ?) is being worked on by some of you. Maybe this mail helps to avoid duplication :-)
Yes it is!
Cheers, Andreas
P.S.: I also have some ideas about improving the ftp plugin. There is a pretty simple ftp library,
Which one?
and I think it does make sense to actually log in an ftp server and stay logged in for all the operations. (unlike wget which logs in and out for every file). This is not only faster but helps with busy ftp sites, too ! Developing the ftp plugin is a high priority and your help here would be appreciated.
Just as hinted in the comments inside ftp.c! Note that you only need to provide the HTML output for FTP directories. Downloads are to be bounced back to dillo for it to forward them to the downloads plugin (that way the whole downloading is centralized in a single place, stats can be provided etc.). I left some code inside ftp.c that shows a beautiful trick to tell whether an FTP URL is a directory when using wget (it probably can be re-used). The most time consuming task with this approach is to parse the ASCII from the ftp server into HTML (easy in theory but you'll find different layouts). In fact that's what I did with and ancient FTP plugin I wrote. If the library you think of using writes HTML itself, great! If not, just tell me to dig in for my old FTP code, and to send it to you. Cheers Jorge.-