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

[Karl Dahlke <eklhad@comcast.net>]

A quick note regarding our arrangement of software into processes:

Having performed a rethink,
and having wrestled with some of the things we need to implement,
I'm convinced we need to stay the course, edbrowse and edbrowse-js.
It allows for some of the asynchronicity we'll want in the future,
edbrowse-js failure or lockup does not bring down edbrowse,
edbrowse can meaningfully run and provide many features even if an
individual or distributer cannot build edbrowse-js,
and most important, different copies of opaquely the same functions,
like get_property_string(object, membername) for instance,
must do two different things in the two processes.
There are dozens of such functions, most of the layer in ebjs.c.
This is driven by parsing, rendering, and possibly decorating html in edbrowse,
assuming there is no js or js is broken or unbuilt,
and also in the js world while the script is running, under a setter.
That html must parse and process in these two different contexts
drives much of the above, so I press on.
Both processes now contain the tidy machinery,
our transformation of the tidy tree into our tree,
some prerendering of the tree, and the decoration of that tree
with js objects, which is done by remote calls from edbrowse
and by native calls in edbrowse-js.
But the code in decorate.c is the same either way.
That is the magic that I have set up.
Geoff, do I have to change cmake files as the .o dependencies change?
Example, both processes now share html-tidy.o and decorate.o.
I really need to learn cmake.

What frightened me initially, passing back the created subtree
from edbrowse-js back to edbrowse, is not so frightening,
as I thought of a clever way to do it last night.
I don't have to pack up and represent the tree in some long confusing ascii
string and pass it back and unpack it again, I can do something else.

Keeping a common tree in shared memory is not practical as:
shmget is not portable to windows, and, more important,
it's not just a tree of nodes but each node may have allocated strings
hanging off of it, for the tag attributes etc,
and I just can't tell malloc to use, in certain situations,
a block of shared memory for its pool.
It would all be a nightmare, and there's really a better way.

So I don't plan to rock the boat in any significant way.
We have a good start and can keep going forward in reasonable steps.
Geoff says our processes and interprocess communication are portable,
with a little work, so that's good.

Karl Dahlke