Re: [Edbrowse-dev] <object> - falling behind

[Adam Thompson <arthompson1990@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]

On Thu, Dec 04, 2014 at 04:16:17PM -0500, Karl Dahlke wrote:
> It might entail a certain amount of redesign, but that's ok.
> I'm not even sure javascript existed when I first wrote edbrowse,
> so you have to move with the times.
> It's a lota lota work, and I don't feel like I could do it myself,
> but probably could with some help.

I agree, it's going to be a *lot* of work to get things right, but I think it's worth it.

One thing I'd really like to accomplish (not sure how yet)
is making it so that the js engine can't kill edbrowse totally, i.e.
at the moment if js segfaults or goes into an infinite loop that's it,
either the browser explodes (in the first case)
or you have to manually kill it (using kill or similar) in the second.
I've had cases in the past where I've been doing work in one buffer,
switched to another to do a bit of research for said work,
and boom the whole thing goes away because of some js.

This leads me on to my next question;
I know we're hoping some day to get a windows port,
but does anyone currently use edbrowse on windows and,
if thread or process management becomes involved,
how much short term effort needs to be made to make things portable (i.e.
do we need to look into cross-platform libraries etc)?
The reason I ask is that, in order to isolate the js (and potentially other
things) from killing the browser, it really needs to run separately with a
communication mechanism (this is common practice in modern browsers,
with some spawning processes and some using threads I think).
Given the state of the code, I suspect processes'd be a bit easier (this is the
model used by chrome according to [1])
(chrome is a google packaged version of chromium essentially).
Any thoughts?

Cheers,
Adam.
[1] http://blog.chromium.org/2008/09/multi-process-architecture.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]