On Sat, 02 Oct 2010 17:31:07 -0400, Diego . <darkspirit5000(a)gmail.com>
wrote:
> Your solution only works for downloads. Your downloader can be made a
> DPI and you can chose wich to use. Actually downloads do not stop if
> dillo close.
I'm well aware how DPI is implemented, and that downloads continue when
Dillo is exited. My solution is intended in part as a temporary measure,
since I need downloads to function regardless of whether DPI is available
or not. I do have concerns, however, with both the specific
implementation and general (perceived) necessity of DPI.
> If the problems are dup2 and sockets dpid can be change to work on
> windows.
> Dillo always ask the dpi that serves a service before conect to it.
> dpid run the DPI so can send dillo the right fd, socket, file or do
> other thing.
I've been working on that, but with very limited success. dup2 and
sockets are the most immediate problem, but there are larger problems
beyond that (for example, packaging Dillo/DPI).
> dpid avoid to load in every dillo code to handle DPIs or external
> programs that will use only one and avoid the synchronize thing.
I don't think basic functionality like local file browsing and HTTPS is
unnecessary "load in every dillo code". If there's any situation where
it's undesired, perhaps the code could be #ifdef'd out and a new autoconf
option added (--disable-local-files, etc.)
As far as sharing bookmarks, cookies, etc. between browser processes: most
major browsers (IE, Firefox, Opera, probably Chrome) allow one browser
process running, and if a second is started, it signals the first to take
some action (create a new window, for instance). That would still require
some amount of IPC, but it's less complicated than DPI, and certainly less
wasteful since you don't have multiple instances loading the same UI,
static libraries, etc.
~Benjamin
