[Edbrowse-dev] interprocess messages

[Karl Dahlke <eklhad@comcast.net>]

As promised, here are some thoughts on messages between eb and the back-end
js process.
Please remember that this is intended as increment,
and so there are messsages to do the things we do today,
while other messages and functionality will come later.

Edbrowse currently maintains a session number,
which is printed by the e command.
In addition to this, edbrowse will maintain a stack number for
the buffers that stack up per session.
Session number and stack number
determines uniquely an edbrowse buffer, a window/document,
and a javascript context.
This combined number will be the context number,
passed between the two processes to identify the js context.

e www.ibm.com
session 1, stack 1, context 100001 (or some such).

Upon browse, if js is not disabled,
eb sends message to js to create the context.
If js is not yet launched, fork/exec the js process.
This process creates the js runtime, allocates the heap, etc.
If this initialization cannot happen it returns an error,
which edbrowse prints, and then disables js,
so you don't get this error again and again on every browse command.
So let's assume js launches and succeeds with a runtime environment.
It creates the js context for the corresponding edbrowse window and returns.

If at any time the js process dies, or is killed,
edbrowse cannot read or write to said process.
At this point it loops through all windows in all sessions
and sets js_dead = true in each of them.
The next browse will reinvoke the js process, as if it were the first browse.
If this succeeds, then in any other session you can unbrowse
and browse, and that action will create a fresh js context for that session.
You could perhaps restart a preexisting web page, even after a js disaster.
Of course we hope these disasters are rare.

There is something that is never done today, but must happen in the future.
One js context, through frames or parent pointers,
can access or modify variables in another js context.
This is another reason to keep them all in the same process.
I'm going to hold off on this for a future incremental step,
but it needs to happen some day.

So far we have the first message, and a status return:

1. create java context for this context number

The next message is of course, and predictably,
to destroy the context, because the window is closed.

2. distroy javascript context for this window

3. destroy javascript runtime process, issued when edbrowse quits completely.
Even if you didn't issue this message, edbrowse exits, and then js exits
on broken pipe.

Subsequent messages fetch or establish objects in the js world,
or properties of those objects.
The return from each request begins with a high level status code.
0 = ok
1 = syntax error or other problem with this particular command.
2 = this js context has failed, set js_dead = true
3 = the entire js heap is compromised, set js_dead = true
   across all sessions and all windows.
4 = js cannot run, no fork, no exec, no js runtime, etc.
   Mark each buffer with js_dead = true and also disable javascript
   so this error does not come again and again with each browse.
   Of course you can re enable javascript and try to browse again.
   Error 4 can only arise from the create java context request.

After the high status number is a low status number,
that edbrowse can use to print a particular error message.
If the status is 0 = ok then the rest of the message
returns whatever edbrowse was asking for.
With this in mind, here are some more ipc messages.

Just as contexts have numbers, so objects within contexts have numbers.
These are assigned by the js process.
They must be, since running javascript can create more objects,
quite apart from those initially created by html.
If edbrowse asks js to create an object corresponding to a dom entity,
js will return the number of said object for future reference.
More on this below.

4. compile and execute a chunk of js code.

5. get property from an object, passes object number and property name,
returns type indicator and a string representation of the property.
Property could be string, integer, float, boolean, function, or another object
whence the presentation is the object number.

6. set property within an object, passes object number,
type of property, and string representation of that property.
Additional parameters are create, when the property is created first time,
and readonly, if the property is created readonly.
Nothing is returned, other than the usual status bytes.

7. Run function, usually an event handler.
pass the dom object number that is the "this" for the running function,
and the name of the function.

Perhaps 2 or 3 more ipc messages that I haven't thought of,
but this should give us the functionality we have today.

Around this I would write wrappers that are essentially the
same functions we have today.
So get_property_string would do what it does now but do so by passing
a message and getting a response.
As much of this as I can do, would make it that much easier to switch over
to the interprocess system.
It would be a manageable increment.

Karl Dahlke