From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) by hurricane.the-brannons.com (Postfix) with ESMTPS id C2C46787DC for ; Mon, 8 Dec 2014 11:29:07 -0800 (PST) Received: from resomta-ch2-10v.sys.comcast.net ([69.252.207.106]) by resqmta-ch2-09v.sys.comcast.net with comcast id R7Qa1p0062JGN3p017TMek; Mon, 08 Dec 2014 19:27:21 +0000 Received: from eklhad ([68.84.191.77]) by resomta-ch2-10v.sys.comcast.net with comcast id R7TL1p00j1gep30017TMgP; Mon, 08 Dec 2014 19:27:21 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Mon, 08 Dec 2014 14:27:20 -0500 Message-ID: <20141108142720.eklhad@comcast.net> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418066841; bh=zkTnguPRsd0AMqbzAC5XAyn1BlrYVp80lMoUesbI/+s=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=jzZdp8svUqU7U5KsEVENy24SHntXdfPOIEcgLyKCGN3L8/WHaZIMHjWAm3LOw5UyG TgmVszNR5pdnRPP00gPcDQFobVdHwRGowRsIYwq8N/Q11bPDTK80OIZRiKSTQYDe9A Zl5N9dZpoUgxbkTqm6z7jbLz3qM2sgRrJA4sKWTROFTHz9iekCwur/gw2SuC0cRnel nNbuCIAtKM6Ec2oya7tBn1TPxI4U8UwX7koAjawzn51kCWB3PGAoRgoGhWrLPwdSbh 6j04NeD/cW3qusTv2hATkFuFK0G0sEx5uBEow3YOQExMu/tp8hz/lwMjw0jPC4I2++ feh3MyObaSPxw== Subject: [Edbrowse-dev] interprocess messages X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 19:29:08 -0000 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