From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) by hurricane.the-brannons.com (Postfix) with ESMTPS id CAB7E78FC0 for ; Sat, 26 Sep 2015 21:39:38 -0700 (PDT) Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by resqmta-ch2-05v.sys.comcast.net with comcast id N4it1r0022Bo0NV014it4G; Sun, 27 Sep 2015 04:42:53 +0000 Received: from eklhad ([IPv6:2601:405:4002:b0a:21e:4fff:fec2:a0f1]) by resomta-ch2-05v.sys.comcast.net with comcast id N4it1r0020GArqr014ituu; Sun, 27 Sep 2015 04:42:53 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.4.2+ Date: Sun, 27 Sep 2015 00:42:53 -0400 Message-ID: <20150827004253.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=1443328973; bh=Tk1kXdeDKf+pvrolTSMpqasXLJPA9lbwM692NSFVA2I=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=rAyQhwj16XUHI9mEw/CloO72C5En1AVxRy5LEJL2C0PcZk0xygur1jZdnTuqivrJL 35YNBmOVXTriLDEiro8z3YRVi1dQYwb6rLY6Y+pSB+boI0n1OTzMImSA5nodxIw2fu WCefkLCdRVoJ7AWRMR/k0rjs1qVPcotGDZCJNaU/yzFYYKfzytPgLsg9Yr13/Hw23S P5No1hrfdbl63tqjFOJdycXlPD2pxeN+BbRmSuslFv+9wB6ntY5oBrsLJX3j+sTIaR Fk5KTQBVNaBbQdKsdqoaIZqN+QfCQp5wwsVDoDrjoDrte6AxjH9BWffTB+1vLYEhZv HjXeCJOdvBXPg== Subject: [Edbrowse-dev] Parallel versions of js access functions X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.20 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 04:39:39 -0000 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