On Sat, Oct 02, 2010 at 06:00:54PM -0400, Benjamin Johnson wrote:
On Sat, 02 Oct 2010 17:31:07 -0400, Diego . <darkspirit5000@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.)
We already agreed quite some time ago on dillo-dev, that HTTPS support could be integrated into the main dillo binary if that would help to create proper HTTPS support. For the current highly experimental HTTPS stuff DPI seems the right place.
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.
Notifying an already open browser instance instead of creating a new process is just a workaround needed because of the long startup times of today's browsers. Cheers, Johannes