Hello, now that i have some free time i want to test the cookies dpi over https like Jorge suggested. I need the server so i ask to the webmaster if he can mount some https pages with cookies for the test, like Jorge suggested too. About other things and thinking about the future, i have some ideas about DPI framework and DPIs that can be useful, maybe. Register and init DPIs I think that the way that gives more adventages is to let dpid manage this using dpidrc to store the list of available DPIs(updated each time dpid is runned with the installed DPIs in the system and in the HOME/.dillo/dpi directory), and the metadata about DPIs: mime types or protocol that manages that DPI, menu entries or buttons that DPIs need and the more important if a user wants use(enabled) that DPI or not(disabled) dpidc need new commands (enable, disable, list DPIs) and individual register of DPIs(dpidc register directory/where/the/new/DPI/is) When a new DPI is register dpid run the DPI and ask the DPI metadata which a new DPI command(<dpi cmd='give_metadata'> ?) and the DPI returns the metadata in a text key-value format, for example a dpi that converts rtf and pdf files to html can send postfix_understand=rtf,pdf mime_understand=text/x-rtf,text/x-pdf (with the right mime type of course) After this dpid stores the metadata in dpidrc file. For example: DPI=rtf_pdf_viewer state=enabled or disabled or ... postfix_understand=rtf,pdf mime_understand=text/x-rtf,text/x-pdf And now three ways to get the new metadata in dillo or the DPIs that understand them: 1) The pasive solution. when a DPI start it read the dpidrc searching the metadata that it understand. (A DPI that manages mime types, so dillo do not need to do it, can make a list with the name and mimes that understand each DPI) 2) Active, but silly one. Dpid re-send the metadata to each other DPI, with a new DPI command, and each DPI redo his internal state with the metadata it understand. This is the worst solution because dpid need to run all DPIs to be sure that metadata arrives to the right DPI. 3) The complex and flexible solution, my prefered one. There is a key-value(send_me) in the DPIs metadata to register keys of metadatas. Dpid understand this key(send_me) and have a internal list to send the metadatas to the right DPI. If a DPI send a key registered with the send_me key while registering, dpid sends the change to the DPI that registered that key so it can update its internal data, caches, whatever. Example: A mime DPI manages the files with mime types unknows to dillo. When it register send this metadata and is stored in dpidrc like part of its metadata send_me=mime_understand Then after the rtf_pdf_viewer DPI is registered, and if it is enabled, dpid send to the mime DPI the DPI=rtf_pdf_viewer mime_understand=text/x-rtf,text/x-pdf and mime DPI updates its state so it can call rtf_pdf_viewer when find a rtf or pdf file. Pros: - It is so flexible that new keys and resources can be used by new DPIs while dpid, or even dillo in some case, do not need to be updated to understand it. - Do not need to modify dillo internals or few Cons: - Dpid, dpidc and DPIs need to be modified - And more, sure Protocols and mime DPIs Based in the xproto DPI i think that a DPI can manage all the protocols and mime formats that dillo do not understand. Dillo simply passes the url or stream(or file location) to that DPI when it do not understand the format and the DPI using a list call the right DPI, script, wathever to manage it. That last DPI open an app, return a data in format that dillo understand(html, gif, jpg, png), etc. Image/objets html tags can call the protocol_and_mime_DPI, with some care and a especial dpi tag, so new formats can be viewed in dillo, if a DPI converts them to formats understanded by dillo, in the right place in the page. A interesting idea is to can embed apps, like sylpheed embed dillo, in the space of a image or object with new tags and/or pasing the WID. The protocol_and_mime_DPI send a html page to dillo when there is more than a DPI or action, download included, for a protocol or mime to ask the user what to do, set default action, etc Pros: - All code is outside dillo - Compatible with all Cons: - Can need news dpi tags - And more, sure HTML GUI When dillo support frames(The only think because i do use an old dillo 0.8.0 patched with frames sometimes is because it have frames)/iframe/objects(this tag can include html to, but frames are better) the dillo GUI can be a html page, with a iframe that contains the viewed web page, and a DPI that modifies the GUI html page. The new thing is that the DPI can use a cache file with that html page that dillo loads at start so dillo init is as fast as now, only loading the DPI when needed. All DPIs that generate html must use the same CSS so all have the same look. Pros: - Make dillo core small - Look is fully configurable - DPIs can register menus and buttons and dillo do not need even to know or have the list of buttons or menus registered in mem an in each dillo Cons: - Need to add remote control dpi tags to dillo - And more, sure Adding all Only frames, and new dpi tags need to be done in dillo core and it gives, when the DPIs needed and dpid are done, a very flexible interface to cordinate DPIs and for example that the DPIs GUI elements can be implemented step by step based on funcionality without touching dillo internals and not all at same modifing dillo core or doing it unestable. Only some ideas. If somebody wants to disscuss them, destroy them, blame about my english or me and my sleep state at this time i have my e-mailbox and eyes open to read all of them. Diego Sáenz/DarkSpirit.