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