[Edbrowse-dev] Parallel versions of js access functions

[Karl Dahlke <eklhad@comcast.net>]

As you know, ebjs.c has functions that act as a layer between edbrowse and the js world.
They send requests to edbrowse-js and receive responses,
and pass them back to the calling function.
Here is the flow of events.
Parse the html text courtesy of tidy,
build our own tree of nodes,
decorate that tree by calling functions in ebjs.c
to instantiate objects and create properties etc,
then, eventually, render the tree.
All good, but as mentioned before, we may need to generate and decorate a
subtree from inside javascript at the moment foo.innerHTML is set to a string.
so the same procedure takes place in edbrowse-js under the control of a setter.
To that end, I now have native copies of many of these layer functions.
Most of these functions were there already, I just had to do a little trickery
so they have the same names as those in ebjs.c.
What's the point?
All the code that decorates the html tree can be shared.
It calls set_property_string(inputTag, "value", val)
for example, and in edbrowse,
when decorating the nodes of the original web page,
that function passes the request over to edbrowse-js and receives an ack.
Inside the edbrowse process, when parsing the html assigned to
foo.innerHTML, the function simply runs native code to make the assignment.

This approach assumes we are going to leave the two processes separate,
as they already are.
That allows for separate layer functions with the same arguments and returns.
That's probably the best path.

Course there's more to do here.
render.c has to be separated into two files,
render.c and decorate.c
The first is true to its name, rendering a tree for the text buffer,
the second generates and decorates a tree with js objects.
The second would be included in both processes,
like stringfile.c etc.
html-tidy.c would also be shared in both processes.
And of course both would have to link with the tidy library.
So code might be moving around a bit.
A commit may say I inserted and deleted 500 lines,
but it's not really that drastic; just rearranging things.

Kevin do you think document.write is similar to innerHTML
in that it is suppose to take effect immediately?
html is parsed and js objects created,
and made available by the next line of the running javascript?
I actually hope the answer is yes,
cause if we're going to go through all this redesign
to make it happen for innerHTML, then document.write
may as well go along for the ride.

Karl Dahlke