[Edbrowse-dev] some progress

[Edbrowse-dev] some progress

[Karl Dahlke]

I thought it worthwhile pushing what I have,
because it is a separate source file that does not interfere with edbrowse,
it saves the work I have done so far,
and it gives you a chance to look and review.
git pull, and notice the files ebje.c and ebjs.h.
This is the edbrowse js interface.
The actual js process I have not written yet; well I started it,
it is coming later.
I thought I would call the source jseng_moz.cpp, for
javascript engine mozilla.
That gives us the option of writing jseng_v8.cpp, etc.
Anyways that's coming, meantime, have a look at these two files if you wish.

The c file is 1190 lines long, so let me point out a couple things.
The last third of it, line 780 on, is strictly dom functions
that could be elsewhere.
They call the primitives that get and set properties,
which send messages to the js process, which manages the js objects.
To illustrate this, look at the function domLink(), line 824.
Compare this line by line with domLink() in jsdom.cpp.
they hardly look like the same function!
The first is like a zillion times easier to read than the second,
and is completely disentangled from all the mozilla js stuff,
and that's the way it should be - which tells me we are on the right track.
This separation is forcing me to rewrite some functions
the way they should have been written in the first place,
basically all the functions after line 780, and perhaps a couple more.

One thing I ran into when thinking about the separation is side effects.
Running js has side effects that use to map back directly into html,
all living together in one process.
These side effects must now come back as part of the reply message.
This processing begins at line 137, and is only partly written.
I'm using the same functions in html.cpp, that were called from jsdom.cpp,
but are now called from here, as per the message received from the js process.
It's more of a transplant than a rewrite.
an example is document.write(), which I have implemented.
The writes build up in a string as js runs, as they do today,
and the string will be added to the html document, as it is today,
only difference is this string is passed back as a side effect to the
javaParseExecute() command.

So there is more to this than I thought, and I don't think it will be done by
Christmas, as I had hoped, but it's coming along.
ebjs.c compiles, and that's all I know.
It is totally untested beyond that point.
You can send any comments about what I have so far.
It's good to be moving forward;
I haven't done any substantial work on edbrowse in about ten months.

Karl Dahlke