From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by hurricane.the-brannons.com (Postfix) with ESMTPS id B27C6786FA for ; Sun, 7 Dec 2014 05:58:53 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ex7so2596044wid.6 for ; Sun, 07 Dec 2014 05:57:08 -0800 (PST) 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=yAeSfVhILXZC8zuXPBAA3/L5tzhY6ZU1td4rvg18NoQ=; b=dpmA7qs7/Y5UEjH3vr6Uk+TsytsJZ5VuFU7AeLz+fqK/GQCiU7vOcO1WPVHZkOi4RK 6btoo1g13iD3ZFzHpm++3j6NPc7RluzMv/5JxzMIO0WtCAj7oru0m/cgdnjhFHfQWlBM ShCpqQwO/R9p2m+CNWBmEA5yG0iBcZAyD/Ok3XuqoQAw4c+wYGVBp01ps0X5qKWqp5B1 5nYJxwVzQVS9Q/CSYVB5dZh/itsVtNTgVem/XxWGUPTFBSOyJ7Rv/8y13t6qVirl6t8F n51n1yKkBFQZyfmuSI3PzFUGTBXTEia6YbxkQE14vtdaaLu7kSKjAbPBK2290hrB1ZgZ rU8A== X-Received: by 10.180.72.199 with SMTP id f7mr17692214wiv.58.1417960628398; Sun, 07 Dec 2014 05:57:08 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id eu15sm5848233wid.18.2014.12.07.05.57.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 07 Dec 2014 05:57:07 -0800 (PST) Date: Sun, 7 Dec 2014 13:57:05 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20141207135705.GO14122@toaster.adamthompson.me.uk> References: <20141106185211.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L5nTHegdhbHhzmSD" Content-Disposition: inline In-Reply-To: <20141106185211.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] IPC, sooner? X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Dec 2014 13:58:54 -0000 --L5nTHegdhbHhzmSD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sat, Dec 06, 2014 at 06:52:11PM -0500, Karl Dahlke wrote: > Another thought on ipc separation. > If we move in increments, I thought maybe it should be the last thing we do, > but now I'm thinking maybe it should be the first thing we do. > Why? > It puts a very clear wall around the js engine. > It lives in the back end js process, > and edbrowse talks to it over a pipe or whatever, > and edbrowse doesn't need to know about the js engine, > and if the js engine changes, in release or to another vendor, > we work within the js process only, > and don't have to touch the bulk of edbrowse. Yeah, that sounds like it could work. > The js process is jsdom.cpp and jsloc.cpp, > and perhaps a couple more files as we advance. > This is in c++, and all the rest of edbrowse is in c, > and maybe html.cpp can revert back to html.c, as it was before. > The more I play with c++ the more not thrilled I am, > and probably wouldn't even use it at all except every js engine uses it. > All the rest of edbrowse, including curl for ftp http smtp pop3 imap etc, > seems to work fine with C. > So anyways, I've practically had a bouleversement on this matter. > It might be worth doing a separation sooner, rather than later. Ok, that sounds like a good idea, though the js process's going to have to have some sort of threading if we want to do ajax etc. > In my last email I talked about render.cpp, but I mispoke. > Yes I very well would write it as render.c, in c, > and it would call the js process to fetch the objects, > as it traverses the tree, to produce the buffer / display. > I did not mean to suggest it would mess with js objects directly, > but rather, here I am at this node, what are the children, > step through them, recursive, etc. > Definitely part of edbrowse proper. How about it calling into dom.c which handles the edbrowse representation of the objects, which could also run in the js (or should that be dom) process, but which provides a layer between edbrowse and our choice of js engine? > I still like the idea of one js process managing > all the js sessions for one edbrowse process. > I think it's a good compromise, and lets us use the js heap effectively. Agreed about the js heap, but threading's going to potentially be painful. I'd also like to separate out downloading from the network somehow such that a large download doesn't block the entire program. This is another thing modern browsers do which edbrowse doesn't (even links can download in the background). Cheers, Adam. --L5nTHegdhbHhzmSD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUhFyxAAoJELZ22lNQBzHOXHYH/i6ImgeIrpp3y2fKWnhFkjYD aG+2prNnvF44g0c3BNQ8ziAzgLXVmRqN+Qzk1AZ/7tr9su3NIwf5p1O6BGpaxkYM xNJkN2sDfJyyE88wuspYzFfx5VM3m4SYxpJ1OoNgwBXem0JNyq5oRPyfsBiH3Ckj jxjHJci6vqq/R0FBI7UbIMy1sG12ZI4iWw17O51zDg63GIyMLxA18AEI7DfgosP6 53t9Hz8+pdxrPPLez+CsinsXK0zjY66o4k9F3WREaSyGbS4yT0mKeXBIEJpGhZgN CO6i3AvTjuI4sDmW1420BJ8wGloHYjLHl2HVFGakV2LVKOEiODhIoZy8rS9dhuc= =Yay9 -----END PGP SIGNATURE----- --L5nTHegdhbHhzmSD--