Re: [Edbrowse-dev] IPC, sooner?

[Adam Thompson <arthompson1990@gmail.com>]

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

On Sat, Dec 06, 2014 at 06:52:11PM -0500, Karl Dahlke wrote:
> Another thought on ipc separation.
> If we move in increments, I thought maybe it should be the last thing we do,
> but now I'm thinking maybe it should be the first thing we do.
> Why?
> It puts a very clear wall around the js engine.
> It lives in the back end js process,
> and edbrowse talks to it over a pipe or whatever,
> and edbrowse doesn't need to know about the js engine,
> and if the js engine changes, in release or to another vendor,
> we work within the js process only,
> and don't have to touch the bulk of edbrowse.

Yeah, that sounds like it could work.
> The js process is jsdom.cpp and jsloc.cpp,
> and perhaps a couple more files as we advance.
> This is in c++, and all the rest of edbrowse is in c,
> and maybe html.cpp can revert back to html.c, as it was before.
> The more I play with c++ the more not thrilled I am,
> and probably wouldn't even use it at all except every js engine uses it.
> All the rest of edbrowse, including curl for ftp http smtp pop3 imap etc,
> seems to work fine with C.
> So anyways, I've practically had a bouleversement on this matter.
> It might be worth doing a separation sooner, rather than later.

Ok, that sounds like a good idea, though the js process's going to have to have some sort of threading if we want to do ajax etc.
> In my last email I talked about render.cpp, but I mispoke.
> Yes I very well would write it as render.c, in c,
> and it would call the js process to fetch the objects,
> as it traverses the tree, to produce the buffer / display.
> I did not mean to suggest it would mess with js objects directly,
> but rather, here I am at this node, what are the children,
> step through them, recursive, etc.
> Definitely part of edbrowse proper.

How about it calling into dom.c which handles the edbrowse representation of
the objects, which could also run in the js (or should that be dom) process,
but which provides a layer between edbrowse and our choice of js engine?

> I still like the idea of one js process managing
> all the js sessions for one edbrowse process.
> I think it's a good compromise, and lets us use the js heap effectively.

Agreed about the js heap, but threading's going to potentially be painful.

I'd also like to separate out downloading from the network somehow such that a
large download doesn't block the entire program.
This is another thing modern browsers do which edbrowse doesn't (even links can
download in the background).

Cheers,
Adam.

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