From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 2E90377E8A for ; Tue, 29 Sep 2015 00:21:56 -0700 (PDT) Received: by wicge5 with SMTP id ge5so136646886wic.0 for ; Tue, 29 Sep 2015 00:25:15 -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=675/pjeDaW43NgTIIkQbnDK5wiiB79XZWkca2mVHaXo=; b=FDS6Hsxr9I+T/XnI6Qud05GxLFEykpglpJyCChJ33yPwaCLFLR+9noIVLJm4r2JEHs N3jQKbcEzqOpPGSrEWp1YsB3321TcqpYr43qZ9JnzQaZitjuEt2sbDbxhYWTn5w/DF7/ HJnVTgEyYDKc7ruN+Wgd+81dV5GPVXAENYXFhwu/TEp0KOnsZU9m9FHqdMUFdGpSTJmA m15gsg6JJHzSqeH1MOASYbfcWEKeYLYrlJ0CaTbGVrIS606Sd0FrAtz4FiPSpGa0KxGg Zkq/g0i25BKRf7Nv36yo5TkumAak9wk4DVGt4Uv765FBhzZPgBxiorvLjw1lQpha4Z0/ +3jQ== X-Received: by 10.180.104.40 with SMTP id gb8mr23675768wib.17.1443511514989; Tue, 29 Sep 2015 00:25:14 -0700 (PDT) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by smtp.gmail.com with ESMTPSA id h6sm22294765wiy.14.2015.09.29.00.25.14 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2015 00:25:14 -0700 (PDT) Date: Tue, 29 Sep 2015 08:25:12 +0100 From: Adam Thompson To: Chris Brannon Cc: Karl Dahlke , ubuntu@geoffair.info, Edbrowse-dev@lists.the-brannons.com Message-ID: <20150929072512.GU2254@toaster.adamthompson.me.uk> References: <20150826100515.eklhad@comcast.net> <20150928044217.GQ2254@toaster.adamthompson.me.uk> <87h9mefu4t.fsf@mushroom.localdomain> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A+KtNVtgI4x4SWvL" Content-Disposition: inline In-Reply-To: <87h9mefu4t.fsf@mushroom.localdomain> 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: Tue, 29 Sep 2015 07:21:56 -0000 --A+KtNVtgI4x4SWvL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 28, 2015 at 08:20:18AM -0700, Chris Brannon wrote: > Adam Thompson writes: >=20 > >> 5. All of edbrowse is once again a c++ program (a minor nuisance). > > > > That assumes we stick with our already rather outdated spidermonkey ver= sion >=20 > Any progress with looking into duktape? > Would you like me to have a go at it? I'm hoping to make some time for it Friday evening and hopefully Sunday, but if you want to look at it as well that'd certainly help. Unfortunately work and life are conspiring to eat all of my development tim= e. I figure if we both keep pushing changes and talking then we can minimise m= erge issues and get this thing done a lot quicker. > > I'm not sure about the portability of but I'm not s= ure 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 t= he time > > because we needed to encapsulate things and allow switching js engines, >=20 > Yes, this is also how I remember that discussion. >=20 > > I was thinking, seeing as we need all sorts of networking, > > asynchronous processing etc, whether it'd make sense to look at using a= library to do this. >=20 > So how would that look, exactly? Ok, I've not studied libuv's api in detail but I was thinking that we really need to have the back-end being a server-type process which handles the networking etc independant of the interface. We then have the interface sat on top with the rendering code (note not the html tidy code) which, either on a request from the user or some UI event requests the current DOM for the current buffer from the browser process. The server would handle spinning up other processes (may be per buffer, or,= I'm not sure). It'd also handle network fetch requests (i.e. e http://some-url.com) since that'd allow all the weird and wonderful networking that servers are starting to use. There are many potential issues here, not least of which is passing the node tree back to the edbrowse client pro= cess in a relatively performant way, though I think passing user changes to the server is relatively well understood. Any thoughts on this? Cheers, Adam. --A+KtNVtgI4x4SWvL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWCjzYAAoJELZ22lNQBzHOk6IIALYiCWQ2UG5AGu7vzXNGVZwH uQExy6YxCdZ1OoZ3XY0l9KIxsOpDP2efg4CvkCRriFbbgxZa4U4n8BZtmCGVCAl6 QyB1/6At3om8kkXbUQcu+f3Qdsrpb+gNads+O+YoX3BYG7vPN557pDXlW2HkPHen 6Okr/B4VFzcQLozNh38G4fegC6zqbB75p+kNulyag13POLNZoYljyBB0mHFbsXTa P9J7uCFcWsF7yIUpMpkuj9pUVIeUvT8whXKtKwQwrmAUck3l6Z/oHBGkhUREp8gI 8G+CsmW5TpDXgtGA7580mTmcTe1HWnUwY/pUOOH8a3gJ9NbUso2KtyBEPeAahH0= =oynW -----END PGP SIGNATURE----- --A+KtNVtgI4x4SWvL--