[Edbrowse-dev] IPC, sooner?

[Edbrowse-dev] IPC, sooner?

[Karl Dahlke]

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.
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.

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.

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.

Karl Dahlke

Re: [Edbrowse-dev] IPC, sooner?

[Adam Thompson]

[-- 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 --]

[Edbrowse-dev] IPC, sooner?

[Karl Dahlke]

> files will get larger as internet speeds,
> amounts of ram and disk space all increase.

Yes this is probably true.

Re: [Edbrowse-dev] IPC, sooner?

[Adam Thompson]

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

On Sun, Dec 07, 2014 at 06:02:43PM -0500, Karl Dahlke wrote:
> > 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.
> 
> right, but perhaps threading could come later, on the next increment.
> I'm thinking of pulling js to its own process,
> with an interprocess communication protocol,
> between edbrowse and js proc,
> that I would present here, first, for review,
> but all having the same functionality as today.
> Then of course we enhance it, and consider other engines, and such.

Ok, would this be launched from edbrowse via fork (thus making another edbrowse process) or be a totally separate js engine with a DOM perhaps?

> > I'd also like to separate out downloading from the network somehow such that a
> > large download doesn't block the entire program.
> 
> I think this is lots of work for little gain.
> Remember, everything asynchronous is a potential nightmare.
> I can download a 300 mb file and it just doesn't take very long.
> I think those features were developed when people were on dial-up connections.
> Really by the time I switch to another session to try to do something else,
> the file would already be downloaded.
> Maybe I'm spoiled by a good connection; but that's how it seems to me.
> And speeds will only increase.

Perhaps, but I've often found myself wishing edbrowse could download in the
background (and straight to disk) particularly when trying to download 1 gb +
isos and the like. Sometimes, like when downloading audiobooks (which sometimes
come as large zip files) you can't use something like wget because there's a
js-driven bit of logic which bounces your browser to the correct page,
and boom, I'm left with a blocked web browser downloading a file which I've got
no idea how big it is (if I forgot to look at the page)
and my machine's fairly resource limited by modern standards (only 1 gb of ram).
Anyway, may be that's just me, and is certainly a topic for a different thread,
but I don't think asynchronous downloads is an out dated feature,
particularly as files will get larger as internet speeds,
amounts of ram and disk space all increase.

Cheers,
Adam.

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

[Edbrowse-dev] IPC, sooner?

[Karl Dahlke]

> 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.

right, but perhaps threading could come later, on the next increment.
I'm thinking of pulling js to its own process,
with an interprocess communication protocol,
between edbrowse and js proc,
that I would present here, first, for review,
but all having the same functionality as today.
Then of course we enhance it, and consider other engines, and such.

> I'd also like to separate out downloading from the network somehow such that a
> large download doesn't block the entire program.

I think this is lots of work for little gain.
Remember, everything asynchronous is a potential nightmare.
I can download a 300 mb file and it just doesn't take very long.
I think those features were developed when people were on dial-up connections.
Really by the time I switch to another session to try to do something else,
the file would already be downloaded.
Maybe I'm spoiled by a good connection; but that's how it seems to me.
And speeds will only increase.

Karl Dahlke