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 08AD377E89 for ; Sat, 26 Sep 2015 07:02:02 -0700 (PDT) Received: from resomta-ch2-03v.sys.comcast.net ([69.252.207.99]) by resqmta-ch2-10v.sys.comcast.net with comcast id Mq5G1r00329Cfhx01q5GUl; Sat, 26 Sep 2015 14:05:16 +0000 Received: from eklhad ([IPv6:2601:405:4002:b0a:21e:4fff:fec2:a0f1]) by resomta-ch2-03v.sys.comcast.net with comcast id Mq5F1r00f0GArqr01q5GaM; Sat, 26 Sep 2015 14:05:16 +0000 To: Edbrowse-dev@lists.the-brannons.com CC: ubuntu@geoffair.info From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.4.2+ Date: Sat, 26 Sep 2015 10:05:15 -0400 Message-ID: <20150826100515.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=1443276316; bh=Z4wIxle8oMcksokGhcoAInwumA/BGfYGnuaHxM9suww=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=lknphse51TbJp0JrIqbDS0H88CRp+wPMnG/ruDqOgGk188qfs+/K4WRAcMmHWMy67 ixvu0WCwXdp2euLZF3Rg9UfwXvUNAi9WWHq1Xiu0bR7W4W4dyTst4Q3951tSb69ILL uUJ51YnY2QEtnSG6O9/W1jAvcLpQ/m6DIvZ0i/ahOtmSIfM67LuNWV1KaEz4Gs7RaF 0uPwVr5rMZujSwYCCvQ96o6dZVl96q1TAk5+m+onQ/MTJU3FgbgJFl8ldHQ8gfLU15 mCdkJhUD0gOkMeF0nJsB0uZOLcIplW7+GD5m/Lf/bx/X7Sz8hstjOi4txZH9fua3yg Iuf4NX7XGw5Lw== 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: Sat, 26 Sep 2015 14:02:03 -0000 As per a discussion that has been taking place off line, and really needs to move to this group, js has to immediately, and within its innerHTML setter, parse the new html text and add the new objects to the js tree, while at the same time, or not long there after, adding the tree of nodes to our tree for rendering. Both processes now need tidy5, html-tidy.c, and at least half of the logic in render.c. With this new revelation, how much easier would all this be if we hadn't separated edbrowse-js into another process! As Fagin says in Oliver, I think I better think it out again. Don't get me wrong - encapsulating js into a separate entity of some kind, with its own source file, and the mozilla details hidden in that source file, and a communication api to and from the js layer, was absolutely the right thing to do. Absolutely! Thank you Adam for directing us down this path. But we did the same for tidy without making another process. Now if they were once again the same process, possibly different threads of the same process, 1. One less hassle with the windows port, as threads are standard and portable, and the spinning off of the process with pipes not so much. 2. js innerHTML and document.write can build js objects and add to our tree of nodes immediately, in the setter, as is suppose to happen, and all in one go, all at the same time. 3. No need to pass the html, or the resulting subtree, back through the pipes and back to edbrowse for incorporation. 4. Better performance (a minor consideration). 5. All of edbrowse is once again a c++ program (a minor nuisance). 6. seg fault on the js side would once again bring down all of edbrowse. This was one of our considerations, but I would hope those seg faults are becoming infrequent, and I think they are. If we really must keep them separate processes, could we use shared memory so both can work on the one common tree of nodes? Is shmget portable to windows? Doesn't shmget require a fixed block of memory of a fixed size? That's the way I remember it. that's how the man page reads. That wouldn't work well with our model; I want to be able to dynamically grow the tree as big as the web page is, without compile time constraints or even run time committment to a size, as we have to do for instance with mozilla's js pool. I mean we could set a pool size at run time for the trees of html nodes managed by edbrowse, wouldn't be a show stopper, just not my first preference. After the last flurry of work settles down and stabilizes, and this has been all good stuff, all moving us forward in the right direction, but after that settles we need to discuss and plan and design before making the next big change. We either need to move some html / render functionality into both processes, with subtree data coming back through pipes, or combine things back into one edbrowse process, or find a shared memory solution. Karl Dahlke