On Sun, Dec 28, 2014 at 01:42:26PM -0500, Karl Dahlke wrote:
> > though perhaps we want to be careful with duplicated efort.
> 
> Right, specialy since there's only three of us.
> Would you like to look at v8?
> So far none of us has a hello world program working.
> There is one in src, that I got straight from google,
> but it doesn't compile.
> 
> make js_hello_v8

Ok, I'll have a look at that. I'm also looking at any other js engines I can
find (preferably not entangled with big browsers)
but so far I'm not sure how mature any such engines are.

> > I'd really like to get a proper DOM independant of js,
> > then plug js into such a DOM.
> 
> Yes, yes, and yes.
> I'm hoping that ebjs.c holds the api that will make this possible.
> That was reason enough to move js into its own process,
> though there are other advantages as well.
> So ... are the prototypes in eb.p, from sourcefile ebjs.c,
> enough to build a dom on top of?
> If not then what else do we need?

I think so from the js side of things.
The problem is the fact that we need to have better support for parsing html
into the initial structure before we load into js.
I think we may also need some more tree traversal stuff inside the js side of
the DOM, and I'm not entirely clear how we handle if js makes wide-spread DOM
changes (like massive amounts of page elements created directly as DOM objects).
I think that support probably needs expanding and linking back to the browser's
representation.
We also need to load in style attributes as well as otherwise there's
a good chance some js will blow up trying to perform some (to us unnecessary)
visual effect and thus not get to some critical part of the code (i.e. onsubmit handlers).
> > As for how much do we need to implement;
> > if we want to have a browser that functions properly on the internet in a few
> > years then all of it.
> 
> Yes I suppose so.
> It doesn't scare me, I just wish we had more resources,
> like maybe an NFS grant to pay us to do it.

More devs are usually helpful, certainly in this case.

> > tracking through js is important,
> 
> I tried in particular to track through the js in the jquery library,
> to see whether edbrowse is a mile away or ten thousand miles away
> from supporting it, but I got rather overwhelmed.
> It's still sitting in my to-do directory.

If we sort the child node and parent node thing (not sure how far that got
done), and probably get all the array types implemented (not just objects)
then we'll be much closer. Throw in support for not just dynamicly altering
selectors but also everything else in the DOM,
and a function for searching through the DOM in various ways,
and we'll have the page creation side sorted I think.

> > make the callback given to curl support both operations,
> 
> Well of course. That's obviously a better design. Thank you.
> I just put the data in memory or on disk,
> according to some variables.

Hopefully, though I'm sure I've missed something important in that logic,
are threads or something involved? Gdb always says that curl spawns a new thread when it downloads, but I assume the curl_perform call blocks, so we should be fine.
> > Yeah, I'm wondering if we want to make that string file more c++ anyway
> Anything that becomes common to edbrowse and edbrowse-js has to be C,
> because edbrowse is entirely in C.
> But making it common might not be worth the bother.
> The routines are different in subtle ways.
> The edbrowse copy calls setError() and such to report error conditions to the user,
> but in edbrowse-js those errors aren't as likely, and would be treated another way,
> so it will probably be 400 lines of code that look similar in 2 places,
> but aren't identical enough to put in common.

Yeah... that should've read "the string handling in that file".
I certainly didn't mean to suggest injecting c++ back into Edbrowse (we just
spent a while removing it). However the js process has to be in c++
(unfortunately) and so we may as well use c++ stuff there.

Cheers,
Adam.