On Tue, Aug 29, 2006 at 06:40:40PM +0200, Diego Sáenz wrote:
Ok, second try(i have changed a pair of things):
The general ideas are to enhance dpid to manage DPIs using services (Like documentation suggest) and to add code to dillo to implement protocols DPIs (without hardcoding them in dillo core), mime handlers DPIs and maybe scripts languages DPIs and content encodig DPIs(now encodigs DPIs are in doubt after your mail)
Dpid will need configuration lines(in dpidrc) to associate server name with DPI path(A dpi dir based path allow a DPI to serve more that one service(in this proposal a javascript DPI will serve protocol_javascript, script_javascript and maybe mime_text/javascript services)).
When dillo finds a protocol that it not handle in core (currently it handle http:, about: and dpi:) it ask for a service for that protocol(to dpid) and dpid returns the DPI from the configuration file(really a socket to comunicate with it). For the service name dillo add the protocol name to the "protocol_" string.
The lines in dpidrc for current services can be this:
protocol_file=file/file.dpi protocol_ftp=ftp/ftp.filter.dpi protocol_https=https/https.filter.dpi protocol_data=datauri/datauri.filter.dpi
I think i will allow the use of '*' to match any(even none) char until end of string in the configuration file. '*' will be checked last. It can be used by a ProtocolNotSupported.dpi that show an error or a page with protocols DPIs to download.
The dpidrc line can be like this: protocol_*=misc/ProtocolNotSupported.dpi
For mime types it works similar. When the user clicks on a link or uses the url bar to view a mime type not handled by dillo the mime type is addeded to the "mime_" string to get the service name(dillo currently handles mime_text/html, mime_text/plain, mime_text/*, mime_image/gif, mime_image/jpeg, mime_image/png). When a not handled mime type is open because a page load dillo add the "_inlined" string to the previous string(example: For a bmp file used like image in a html page dillo will try the mime_image/x-bmp_inlined service)
The use of '*' wildcard allow the use of one DPI to manage both services with only a configuration line if user wants.
About mime type check/detection i am thinking on diferent options (mime detection/check go before mime DPIs) 1a. Fixed service called for pages without mime types and ocet/stream (using this like unknown mime type) that returns a detected mime 1b. Fixed service called for pages without mimes and for a list of configured mime types in dillorc 2a. Check service per mime type with service names like mime_check_MIME/TYPE. Dillo send actuall type so the DPI handling the service can do something if detected mime is diferent from the server sended one.(ask the user, ignore error, stop load ...) 2b. Like 2b, but only ask for a list of mimes configured in dillorc
Scripts and content encoding work similarly.
For more details i can send how the dpi tags will be and more about dillo-DPIs communication and dillo internal changes.
At this phase I'd appreciatte much more the "general picture" rather than some implementation details. I mean. What's the problem you're trying to solve? What's the scheme you propose? Have you tested it to suit current functionality and maybe other problems too? For instance, if you click over a network radio link, it's not a good idea to use dillo to download the link data and to pass it via dpi to a dpi-radio plugin (and worst, to cache the stream! :). It's much better to cut the network connection from dillo and to handle the URL to a dedicated radio-stream program. In the case of a PDF. It would be nice to save the data to some temporary directory while you pipe it into xpdf or to let the user choose whether to save with a dialog. Same for a movie stream, etc, etc.
With regard to gzip encoding: zlib can do gzip decoding, and as it is already linked in Dillo, gzip decoding can be implemented inside Dillo (not using a dpi).
Oh, i forgot it.
Will you implement this?
This also avoids multiple dpi passes. For instance with dpi- decompress, gzipped isolatin2 would require one dpi pass for uncompress and another for latin2 to utf8.
Inside-Dillo decoding also allows the idea of having a compressed cache in the future.
I unknown if i can implement content encoding in dillo internals so i will move it after dpid changes on implementation complex.
IMO this is much simpler tan what you're willing to try first. Beware. -- Cheers Jorge.-