Ami,

I read the dpi1 document. As far as I can see, it refers to DPI's having a "scope" which URLs can fall inside of, and this scope is always prefixed with "dpi:/". Are you saying that: 1) There is no restriction in the code to the dpi:/ prefix? or, 2) You have no objection to removing the current restriction to dpi:/?

If 1, please explain (or point to any documentation/source code that explains). As near as I can see dillo/src/IO/Url.c:a_Url_get_ccc_funct() branches to a_Dpi_ccc only if dpi:/ is the prefix. Furthermore, dillo/src/capi.c:a_Capi_open_url() branches on whether url_str starts with "dpi:/".

If 2, do you already have plans in place for maintaining a list of which plugins handle which prefixes?

It is simpler than 1) and 2) ! As SSL has a high priority on my list, it would be a matter of writing an external program that does https (given the URL), retrieves the resource, performs any other required tasks and reports it results somewhere. That is, I'd make all the necessary bindings/extensions in dillo's core to accomodate the plugin. AFAIU, the most basic communications required between dillo and the https dpi are: 1) -> Send the https URL to retrieve 2) <- Maybe make the user confirm the certificate acceptance 3 <- https resource Please inform me about any other required communications. As for developing the prototype, just as stated in the dpi docs. assume you have the answer from dillo and go on! That's all. Hope this helps Jorge.-

Such an "external program" already exists -- it's called wget. And if you wrote the dillo<->wget interface flexibly enough, you get https, ftp, and use of http proxies all for the price of one.

Why not have compile time options to include or not include both the built-in http protocol support, and the option to use wget. That way, anybody using Dillo in an embedded application who just needs http support can use the built-in support, but anybody requiring additional functionality can use wget. John.