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

[Adam Thompson <arthompson1990@gmail.com>]

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

On Mon, Sep 28, 2015 at 08:20:18AM -0700, Chris Brannon wrote:
> Adam Thompson <arthompson1990@gmail.com> writes:
> 
> >> 5. All of edbrowse is once again a c++ program (a minor nuisance).
> >
> > That assumes we stick with our already rather outdated spidermonkey version
> 
> Any progress with looking into duktape?
> Would you like me to have a go at it?

I'm hoping to make some time for it Friday evening and hopefully Sunday,
but if you want to look at it as well that'd certainly help.
Unfortunately work and life are conspiring to eat all of my development time.
I figure if we both keep pushing changes and talking then we can minimise merge
issues and get this thing done a lot quicker.

> > 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,
> 
> Yes, this is also how I remember that discussion.
> 
> > 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.
> 
> So how would that look, exactly?

Ok, I've not studied libuv's api in detail but I was thinking that we really
need to have the back-end being a server-type process which handles the
networking etc independant of the interface.
We then have the interface sat on top with the rendering code (note not the
html tidy code) which, either on a request from the user or some UI event
requests the current DOM for the current buffer from the browser process.
The server would handle spinning up other processes (may be per buffer, or, I'm not sure).
It'd also handle network fetch requests (i.e.
e http://some-url.com) since that'd allow all the weird and wonderful
networking that servers are starting to use.
There are many potential issues here,
not least of which is passing the node tree back to the edbrowse client process
in a relatively performant way, though I think passing user changes to the
server is relatively well understood.
Any thoughts on this?

Cheers,
Adam.

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