From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 6F7627895D for ; Sun, 27 Sep 2015 21:39:03 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so84035031wic.1 for ; Sun, 27 Sep 2015 21:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=bSoHTtBRlhR/20kGdSKJ6uiuQhbGH0HkDvMGxpbyQJs=; b=ej8HTNcqQ6N+/3FPaTT9pxcXrS5Vk7wYDEWj6sdImazyZOH4DEUlK+7MSwzMOnIKmA rbNuRHAGjxNrwrezX2iooFSXTsKNmfkysQEuYemvZjH5r4aGzls8viCGlKUwMoMUClVO 3ThJcn4mBIP1Cdy+tiAHrh57AYcU21QVypoVDDP61xpJqpFMXDSpwUCYG2o0NnlGDV8Z 1juQ4zJtTddC8VJCUboBmke3UyKzTMWiyM0ya/TXD27/QD9z7df9HzDzdW/3tf8JljV1 fN9ihRbzh+qZLWjG/+HQBtLVS0Vjdk0Ala/pNGLlROPUvdkGyh4qKWKC6loXHmb1d1Jc Pg5w== X-Received: by 10.180.211.10 with SMTP id my10mr16735827wic.84.1443415339819; Sun, 27 Sep 2015 21:42:19 -0700 (PDT) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by smtp.gmail.com with ESMTPSA id jq10sm16130408wjc.40.2015.09.27.21.42.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 27 Sep 2015 21:42:19 -0700 (PDT) Date: Mon, 28 Sep 2015 05:42:17 +0100 From: Adam Thompson To: Karl Dahlke Cc: Edbrowse-dev@lists.the-brannons.com, ubuntu@geoffair.info Message-ID: <20150928044217.GQ2254@toaster.adamthompson.me.uk> References: <20150826100515.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SvyA5ywaG/v2A5dH" Content-Disposition: inline In-Reply-To: <20150826100515.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [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 04:39:04 -0000 --SvyA5ywaG/v2A5dH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 26, 2015 at 10:05:15AM -0400, Karl Dahlke wrote: > 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. Yes, that would appear to be the case. > 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. >=20 > 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 f= ile, > 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. Thanks, shame it's not quite working out as hoped... but see below. > 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, >=20 > 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. Hmmm, see thoughts below re: the possibility of a portable (well ok external library but portable from our side) way of making this work. > 2. js innerHTML and document.write can build js objects and add to our tr= ee of nodes > immediately, in the setter, as is suppose to happen, and all in one go, > all at the same time. Agreed, this would work, but we'd run into issues when we make this stuff asynchronous (that needs to happen soon). > 3. No need to pass the html, or the resulting subtree, > back through the pipes and back to edbrowse for incorporation. The subtree looks difficult to do without some sort of intermediate representation. > 4. Better performance (a minor consideration). Not necessarily. One of my issues with multi-threading and our current code base is that there are simply entire chunks which aren't thread-safe and wo= uld require all kinds of mutex hell to make run reliably. > 5. All of edbrowse is once again a c++ program (a minor nuisance). That assumes we stick with our already rather outdated spidermonkey version (firefox is on... version 31 or probably more like 35 now, not sure when they'll cut a new smjs release if ever). > 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 th= ey are. Not to mention the possibility of js-induced deadlocks etc in (for example) html node tree access. > 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 m= anaged by edbrowse, > wouldn't be a show stopper, just not my first preference. I'm not sure about the portability of but I'm not sure = that's where we should go either. I think, if I remember my original design correctly, I was thinking more of having the DOM in a separate process, may be even one per browser buffer. We went for just moving the js at the t= ime because we needed to encapsulate things and allow switching js engines, but the more I learn about ajax the more I believe we really need buffer-specific browser processes communicating back to the Edbrowse main u= i somehow. I've talked about this with someone at work actually and he agreed that for something like our ui it makes sense to adopt a sort of "browser as a serve= r" model where the networking, html parsing etc is all handled in a server pro= cess and then the interface does the rendering. Now for the portability discussion (se above). I was thinking, seeing as we need all sorts of networking, asynchronous processing etc, whether it'd make sense to look at using a lib= rary to do this. In particular I was thinking of libuv as I think (from memory) it has a Windows port. > 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 process= es, > with subtree data coming back through pipes, > or combine things back into one edbrowse process, > or find a shared memory solution. Or head down the above route. I'd also throw out there that we have web sockets becoming a progressively larger "thing" in web development, so my original plan of just using libcurl to implement an XMLHttpRequest ob= ject just won't fly any more. Js now expects not only full networking, but also (apparently) the ability to read files from the user's computer (s= ee the FileReader object on the MDN site for example). I believe gmail actually uses such an object in the non-basic file upload mechanism (it's certainly not a standard multi-part form upload). Cheers, Adam. --SvyA5ywaG/v2A5dH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWCMUpAAoJELZ22lNQBzHOSFQH/j0lNUEz7M6cvoNfcrLo0mwd erzGkP+a2hLR1f10hGe7CnvkD7uQvdlUDVT8TEHbPw5ZTTu//+2mUhsEfcuCwmgm Q+0KQgIpCr4NN0uxEVpJXByYCdv4/galIJKyOlb8dPd6l1GHzn4YFL5P2rAQkN34 Qd6A+cixSBHtw5oPOsKe96Gp8H0gsKBx3oJLZ8CSdwmG00/iUQhy6HuylyQdvovv bTH3mgQahLoGlgh6ly/DYDWx+LW3jYQj+PcwSYQyUl0WB6GntyV4ZZGc+yWN50OZ Uk++joNvw5phztcz+H+BUC5RrBdJLJ7cw6TftP0yIv1E76ih6CJ2rGmW07wO8ms= =yB+y -----END PGP SIGNATURE----- --SvyA5ywaG/v2A5dH--