From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) by hurricane.the-brannons.com (Postfix) with ESMTPS id E873C77DF6 for ; Mon, 21 Dec 2015 11:05:08 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-03v.sys.comcast.net with comcast id wK2h1r0022S2Q5R01K5Fzc; Mon, 21 Dec 2015 19:05:15 +0000 Received: from eklhad ([IPv6:2601:405:4001:e487:21e:4fff:fec2:a0f1]) by resomta-ch2-16v.sys.comcast.net with comcast id wK5E1r00g2MDcd701K5EzP; Mon, 21 Dec 2015 19:05:14 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.6.0+ Date: Mon, 21 Dec 2015 14:05:14 -0500 Message-ID: <20151121140514.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=1450724715; bh=OpgSGzCOb+STxhBawUWbVAVLHavAKB2ywV0plZfu1/M=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=a7Gs+gLhHPxT0yyCQ5ccDUBxFEEJOJVegufaYzz9WYVZbyvkB2FIqm4IM7R30tqS6 xSpFO09OPVqYmvKEmGKbo6v2a8/cBVgNC9AijSEDrCCUH/eL4z671mEAMLp0kti8OL n8VyoRT9kv/qlUBDD/am6yv4Az6p86S/H86vBQEc/7OmME0mJTSVRLTYCF+8LfRjeA G0PUwHl+HhKh7E0qUbvCq5sG5eLrS/h1MvSudtx2KyXewaekVeaA8fTPE3aK1eVsdb t+0bdd8BA0kd9RG82kM90NaYkXk2tAu0olbri5l1l+XDZfJ+yTeRma+e1m3dap0pIT B0X16iKGKmGgw== Subject: [Edbrowse-dev] A Great Sucking Sound from the South 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, 21 Dec 2015 19:05:09 -0000 That sucking sound you're hearing is the js process pulling in more and more of the edbrowse machinery. And that's not necessarily a bad thing. It started with basic memory, string, and url routines, so we made a couple sourcefiles common to both processes. And the common files could remain in C. No problem. Then, Kevin discovered that innerHTML has to run right now, as a native method in js, because the very next line of js code might depend on it. So all the html parsing and decorating with js objects and the like had to be part of the js process. Course it still has to be part of edbrowse, because we want to parse and render our html even if js is not running or has failed. So more files are common: html-tidy.c and decorate.c. These all go into common.a. Do I hear more sucking sounds? Certain javascript objects send an http request and get data back. Question: must this ever happen now, wherein the next line of js depends on it? If yes, and I think this would be a yes, like innerHTML, then the http machinery has to be part of edbrowse-js. Well maybe it's just a simple curl call. Maybe we don't need to share http.c, which does so much more. We don't need ftp downloads and redirection to plugins and all those other things. But ... I fear we do need more than the curl wrapper that Kevin has put together as a test. We need the file of certificate authorities, certfile in .ebrc, and the websites that should not use certificates, and the entire proxy database to know where and when to proxy, and the user agent, and for asynchronicity in the future, the ability to fork and perform the entire http transaction in the background. If you put this altogether I think you'll agree we can't just write a little 50 line wrapper around curl, we need a good percentage of http.c. I think another file is shared. But there's more. How does it know all the certs and proxy and such? Pass that through args or environment to edbrowse-js? I don't think so. Probably the js process should read and parse the config file just like edbrowse does. Then it too would have our setup for proxy and certificates and the like. Obviously we're not going to share main.c between the two processes, so readConfigfile() would have to move to another source file that is shared, so it can be called from both processes. Course js doesn't care about mail accounts or plugins or most of what's there, but it could retain the structures that it does care about. One of these is jspool, which we now pass as an argument to edbrowse-js but wouldn't need to if it was reading .ebrc as well. I'm not going to do any of this tomorrow, just putting some thoughts out there for comment. Karl Dahlke