From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 5FE4F77B1A for ; Sat, 6 Dec 2014 15:53:56 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-02v.sys.comcast.net with comcast id QPs31p0024ueUHc01PsCdv; Sat, 06 Dec 2014 23:52:12 +0000 Received: from eklhad ([68.84.191.77]) by resomta-po-03v.sys.comcast.net with comcast id QPsC1p0021gep3001PsCCg; Sat, 06 Dec 2014 23:52:12 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.1 Date: Sat, 06 Dec 2014 18:52:11 -0500 Message-ID: <20141106185211.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=1417909932; bh=KqZimpmldowwbM/aUyk0Bt20CEH0E+MDy4s3qwu4rdk=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=m8sKF5RDUzlRSfWf4PHY7NPYnSC66jA2k0h2AeDep2pN1TPQEEq5iPWsk30TUxL15 WA5ZbsotNuYwHJYLfC82FVCtf4kAil4wCVUqU+hj41VT9Rofz7lR7oUQXfwIdF9xw2 xZbX6QussYc+m5WHOGNuwcPWkeL8z3LxVfM2UEZiAfgM91YvfLQhAhmNSPA9IDit9o mf8uWsoH+5PFSHkaGEwxTf8l6kIRL7tNe6WhvSIP+VmXGr9BwHAhQxk9zRl7MSF3sm A9116fiiIkuBX4pzw5OMbj83iM+RAUws5PkKJCZwQFogK+o9TiOEj9LSV+RW/EAoQ9 feU0Seu0Z6GMw== Subject: [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: Sat, 06 Dec 2014 23:53:56 -0000 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. 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. 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. 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. Karl Dahlke