From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by hurricane.the-brannons.com (Postfix) with ESMTPS id C12E8787DC for ; Sat, 6 Dec 2014 11:30:17 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id y19so3349404wgg.28 for ; Sat, 06 Dec 2014 11:28:33 -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=kA4jljKAD8BnPZHb1/63j52fmYB2gIWOi7EfGranJJs=; b=jBjFpLwDNGJxvhXyGFG8VdL6EzltgNZTIGoXx/3w0xy2cdfouCCDTMBvW2P3LWs8sv MltPLlEfLWpNp89iO3lQksdzFwfzcQ8doG0Pfv3XSg9goS3wg3tmpoeWhB2Ra99IYMV2 aT2PRxdXnTSXMcrR8rUENHvhlgxd62uHfOzSVXS3yLD+c6Rr4Ed+E/xHPNyQi0+0+Wz4 8mQG4EoSgbjUiKN88GOMA7/vW3weZn8fBplJRELUY0yuRQp4oILp3zU7x0OZvw8X/igh 4UBQ1+uQbcA6HOYNegHVlzD78ft8nHVZmjNX6HNZxOfv3y/Ng8tRVmy7LNzyVOUBcyQD WHgw== X-Received: by 10.180.100.98 with SMTP id ex2mr13157952wib.58.1417894113200; Sat, 06 Dec 2014 11:28:33 -0800 (PST) Received: from toaster.adamthompson.me.uk (toaster.adamthompson.me.uk. [2001:8b0:1142:9042::2]) by mx.google.com with ESMTPSA id gl11sm24404412wjc.40.2014.12.06.11.28.31 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Dec 2014 11:28:32 -0800 (PST) Date: Sat, 6 Dec 2014 19:28:29 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20141206192829.GN14122@toaster.adamthompson.me.uk> References: <20141106074714.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jnYfR+Q8IWTs8BNa" Content-Disposition: inline In-Reply-To: <20141106074714.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] IPC 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: Sat, 06 Dec 2014 19:30:18 -0000 --jnYfR+Q8IWTs8BNa Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 06, 2014 at 07:47:14AM -0500, Karl Dahlke wrote: > While Adam's arguments for a multi-process approach are compeling, > I still wonder if that should wait for a future date. > I guess there are two approaches: a complete rewrite that changes everyth= ing, > and leapfrogs all the way to the end, > or incremental changes to get us there. > If we can move step by step, I think the ipc separation would be > one of the last steps to take. > Given our limited resources, > just three volunteers working in spare time, > I kinda think we should go incremental, > though I realize there may be some jumps that just can't be done that way. I can see why, but I'm worried of incrementally heading in whatever directi= on we need to get the current increment done. I'm not saying we need multi-process tomorrow, but that's where I think we need to be heading, and if we increment in that direction then I've no problem with an incremen= tal=20 approach (assuming everyone's agreed on this as the final outcome). > I'm trying to think of a piece or two that I could work on, > that would be a step in the right direction no matter what, > and would perhaps be useful without a complete rewrite. > I could work on render.cpp, a brand new sourcefile > that starts at the top of the js tree, the document if you will, > and traverses it, and builds the text buffer > with its hyperlinks and forms and such. > In any other browser this piece of software creates the display on the sc= reen. > That would be something we will need, I imagine, > no matter what, in the future, > and would not disturb any of the existing machinery. > It's just there when we're ready to use it. I'd rather render.c which'd be a proper DOM implementation which can then be plugged into by whatever js machinary we use (whether it be in C, C++ or whatever), since I'm concerned that if you go down the js document t= ree route we'll end up tied to a particular js engine implementation. Better still, I'd really like it if we could have a module which handles di= splay, and modules which handle what to display e.g: the display (or ui) module handles how to render a line to the screen (incl= uding support for hyperlinks etc) We then have a module which handles text, one which is a browser implementa= tion, an email implementation and a database implementation. This is somewhat like we have now, with the difference being that I'd like = to increase the separation, with a future idea to be plugin support. To get there incrementally, it'd be good if we could work on separating wha= t we already have into such a display module (personally I'd prefer to writ= e it in c rather than c++ but whatever) and see where that takes us. Going back to the philosophy which has been talked about in previous thread= s, what'd be really nice is an interface library which handles commands and displaying etc which can then be used by software wishing to provide an edbrowse like ui (yes, I've wanted to do this for other projects before). This is probably not that plausable, but if we can head that way with the code I think it'd make things easier t= o=20 work on (i.e. clean up the code and separate things where we can). >=20 > Circling back to ipc, if we stay with mozilla, > as chris suggests we should, and I'm really up in the air on that one, > but if we do, the fixed js heap will really come to haunt us > in an ipc world. > Right now we have the law of large numbers on our side. > All the js sessions together, under edbrowse, > live within a js heap of 128 meg or whatever you allocate, > and by averages that's pretty safe. > One instance might consume 50 meg but the others are all small. > Now if we spin off a separate process for each js, > we have to allow a heap of 50 meg for each of them, > and pretty soon js consumes all your ram, mostly for doing nothing. > Maybe that's ok in virtual memory, > where allocated yet unused pages just don't do anything, > but it really rubs me the wrong way. > I wish the js heap in mozilla was properly dynamic. Yeah, that *SUCKS* a lot. As I said, this is going to be hard and won't happen quickly. > I suppose there could be one js server, in one back-end process to edbrow= se, > that manages all the sessions, > then we benefit from the average again, > but if js crashes you lose all your js sessions, > but you still have all your edbrowse buffers. > Maybe that's a good compromise. I toyed with this idea but there has to be a nicer way. > Lots to think about here. Indeed, and I think we've got a bit of time to discuss things. I'd rather know where we're headed than start heading there and discover we were heading to the wrong place half way. Cheers, Adam. ps: when I've got a bit of time (over christmas probably) I'm happy to investigate how separated the UI and backend code is and what = it'd take to increase this separation if we want to. --jnYfR+Q8IWTs8BNa Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUg1jdAAoJELZ22lNQBzHOlIAIAN48F0DiG8oDZHV3Y6zNU+NR 3IfGZy/39D17MjkdSAusggtoM9Z8Kj168SUHBPr3Y83VCpYGDYVICMhI7mRp7f9u ajIxdxbm2pL3pTJsRTWVCsrtwWS6VXXMRAGwbRCExsgNA1BwbkMW1F77SS5BcGAF 9Nd33YTuOO+phRqgXVg5kchZTRsTTRLoVi9q3XEks5DRABa25rg0s4hHG/5Qukf+ 5PLAslsTv88U7eDzHYFjSSByDZJrkfI3jYmO0kyiR0k9qAWzquy72fzuWK+NvojY Nh7t5X/3w9rx77BlGYN3pgHjbkpHwlZNBye2YhLDjs3Sqx9kB4BaAC3NsRgr72E= =qQw3 -----END PGP SIGNATURE----- --jnYfR+Q8IWTs8BNa--