From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 202B677E8A for ; Mon, 28 Sep 2015 10:25:24 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-10v.sys.comcast.net with comcast id NhSH1r0022PT3Qt01hUiWN; Mon, 28 Sep 2015 17:28:42 +0000 Received: from eklhad ([IPv6:2601:405:4002:b0a:21e:4fff:fec2:a0f1]) by resomta-ch2-14v.sys.comcast.net with comcast id NhUh1r00M0GArqr01hUiPb; Mon, 28 Sep 2015 17:28:42 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke References: <20150826100515.eklhad@comcast.net> <87h9mefu4t.fsf@mushroom.localdomain> User-Agent: edbrowse/3.5.4.2+ Date: Mon, 28 Sep 2015 13:28:41 -0400 Message-ID: <20150828132841.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=1443461322; bh=r0woNMV93rntrbRK5si0pqnJIDrC8fk/Me8xwlbD4XI=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=GVHvtsF58rVTWxEearvJ9PuV8VA7ecHcbnN4RRWdPHIi5YiTmCe+alpgDBRC8rkeD PFABkF+2Tr3OqKjplGNTs7kh9PcQYmsSaJ2ABShoInFiQrBiTuTn14fGxHcWyQNnJB +UrRwez2IGuh2ddpMVlsgxhs8tRmge/8VuWPpZSfQzv5h23aPZaCodMPx/zy5uGeWv v/+ZKtLGitH5Y10FYz28vuEeoKyf5sbLQMa38nrKdI8VR/F13HZHV26E6uOZB8WX1B OpwxOjCaAkXKm51l0YebzU288EOmBWrjIMUPjo+KMiVRMcWGg6ug4JzzzKoNF7cP6D SfrxV3ZVeTYhw== Subject: [Edbrowse-dev] edbrowse-js back in the fold?? 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: Mon, 28 Sep 2015 17:25:24 -0000 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