Re: [Edbrowse-dev] edbrowse-js back in the fold??

[Adam Thompson <arthompson1990@gmail.com>]

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

On Sat, Sep 26, 2015 at 10:05:15AM -0400, Karl Dahlke wrote:
> As per a discussion that has been taking place off line,
> and really needs to move to this group,
> js has to immediately, and within its innerHTML setter,
> parse the new html text and add the new objects to the js tree,
> while at the same time, or not long there after,
> adding the tree of nodes to our tree for rendering.
> Both processes now need tidy5, html-tidy.c,
> and at least half of the logic in render.c.

Yes, that would appear to be the case.

> With this new revelation,
> how much easier would all this be if we hadn't separated edbrowse-js into another process!
> As Fagin says in Oliver,
> I think I better think it out again.
> 
> Don't get me wrong - encapsulating js into a separate entity of some kind,
> with its own source file, and the mozilla details hidden in that source file,
> and a communication api to and from the js layer,
> was absolutely the right thing to do. Absolutely!
> Thank you Adam for directing us down this path.

Thanks, shame it's not quite working out as hoped... but see below.

> But we did the same for tidy without making another process.
> Now if they were once again the same process,
> possibly different threads of the same process,
> 
> 1. One less hassle with the windows port, as threads are standard
> and portable, and the spinning off of the process with pipes not so much.

Hmmm, see thoughts below re: the possibility of a portable (well ok external
library but portable from our side) way of making this work.

> 2. js innerHTML and document.write can build js objects and add to our tree of nodes
> immediately, in the setter, as is suppose to happen, and all in one go,
> all at the same time.

Agreed, this would work, but we'd run into issues when we make this stuff
asynchronous (that needs to happen soon).

> 3. No need to pass the html, or the resulting subtree,
> back through the pipes and back to edbrowse for incorporation.
The subtree looks difficult to do without some sort of intermediate
representation.

> 4. Better performance (a minor consideration).

Not necessarily. One of my issues with multi-threading and our current code
base is that there are simply entire chunks which aren't thread-safe and would
require all kinds of mutex hell to make run reliably.

> 5. All of edbrowse is once again a c++ program (a minor nuisance).

That assumes we stick with our already rather outdated spidermonkey version
(firefox is on... version 31 or probably more like 35 now,
not sure when they'll cut a new smjs release if ever).

> 6. seg fault on the js side would once again bring down all of edbrowse.
> This was one of our considerations,
> but I would hope those seg faults are becoming infrequent, and I think they are.

Not to mention the possibility of js-induced deadlocks etc in (for example)
html node tree access.

> If we really must keep them separate processes, could we use shared memory
> so both can work on the one common tree of nodes?
> Is shmget portable to windows?
> Doesn't shmget require a fixed block of memory of a fixed size?
> That's the way I remember it.
> that's how the man page reads.
> That wouldn't work well with our model;
> I want to be able to dynamically grow the tree as big as the web page is,
> without compile time constraints or even run time committment to a size,
> as we have to do for instance with mozilla's js pool.
> I mean we could set a pool size at run time for the trees of html nodes managed by edbrowse,
> wouldn't be a show stopper, just not my first preference.

I'm not sure about the portability of <shared_memory_api> but I'm not sure that's where we should go either.
I think, if I remember my original design correctly,
I was thinking more of having the DOM in a separate process,
may be even one per browser buffer. We went for just moving the js at the time
because we needed to encapsulate things and allow switching js engines,
but the more I learn about ajax the more I believe we really need
buffer-specific browser processes communicating back to the Edbrowse main ui somehow.
I've talked about this with someone at work actually and he agreed that for
something like our ui it makes sense to adopt a sort of "browser as a server"
model where the networking, html parsing etc is all handled in a server process
and then the interface does the rendering.

Now for the portability discussion (se above).
I was thinking, seeing as we need all sorts of networking,
asynchronous processing etc, whether it'd make sense to look at using a library to do this.
In particular I was thinking of libuv as I think (from memory)
it has a Windows port.

> After the last flurry of work settles down and stabilizes,
> and this has been all good stuff,
> all moving us forward in the right direction,
> but after that settles we need to discuss
> and plan and design before making the next big change.
> We either need to move some html / render functionality into both processes,
> with subtree data coming back through pipes,
> or combine things back into one edbrowse process,
> or find a shared memory solution.

Or head down the above route. I'd also throw out there
that we have web sockets becoming a
progressively larger "thing" in web development,
so my original plan of just using libcurl to implement an XMLHttpRequest object
just won't fly any more. Js now expects not only full networking,
but also (apparently) the ability to read files from the user's computer (see the
FileReader object on the MDN site for example).
I believe gmail actually uses such an object in the non-basic file upload
mechanism (it's certainly not a standard multi-part form upload).

Cheers,
Adam.

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