El Sun, 27 Aug 2006 12:53:47 -0400 Jorge Arellano Cid <jcid@dillo.org> escribio:
Hi,
On Fri, Aug 25, 2006 at 03:49:10AM +0200, Diego Sáenz wrote:
Hello again.
[...]
I mail this because i want coments and help. If you has read this boring (and bad +writed) text until here, please do not think on comments or help, Just do if! :) [...]
I have started to code my proposal.
Beware, your first mail is very hard to read an understand (I don't understand it for instance).
Sorry. I almost forgot how to write english when i do not write it in a long time.
The subject matter is complex, so I'd advice you to: take your time, re-think, be more careful with your english, and to try to express the ideas as clearly as possible.
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.
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.
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. I hoppe it is more clear now. Diego