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.) 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
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
On 10/4/10, Johannes Hofmann <Johannes.Hofmann@gmx.de> wrote:
On Sat, Oct 02, 2010 at 06:00:54PM -0400, Benjamin Johnson wrote:
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.
Fair enough -- but local file browsing? Does that seriously bloat the browser so much it has to be implemented as an external service? That's something I'd expect *any* browser (or similar program) to have built-in.
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.
I can see I'm not likely to win this one, so I suppose I'll drop it. At any rate, I did just think of a possible way to (re)implement DPI, using a dsock-like wrapper that hooks into the Windows messaging system. I *think* fltk can expose a window's internal handle, which is the main thing you'd need. Anyway, I'll get back to you once I've done a bit more research, and in the mean time, I'll try to split up that patch. I can think of worse ways to kill three hours... :-) Cheers, ~Benjamin
participants (2)
-
Johannes.Hofmann＠gmx.de -
obeythepenguin＠gmail.com