From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 26AE079046 for ; Fri, 6 Nov 2015 11:50:47 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-02v.sys.comcast.net with comcast id eKpH1r0032Qkjl901KrEad; Fri, 06 Nov 2015 19:51:14 +0000 Received: from eklhad ([IPv6:2601:405:4080:53:21e:4fff:fec2:a0f1]) by resomta-ch2-15v.sys.comcast.net with comcast id eKrE1r00D1DsNmD01KrEa6; Fri, 06 Nov 2015 19:51:14 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke Reply-to: Karl Dahlke User-Agent: edbrowse/3.5.4.2+ Date: Fri, 06 Nov 2015 14:51:14 -0500 Message-ID: <20151006145114.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=1446839474; bh=y2x0PxxKtcEXi8RRkTsN2TJJkkSlPukysb+UeLh3nes=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=G7z3qc8plcF88vuSTB07C9reaxYbC/lR2qzyR0kcymT1qsXypkceFbbcg/lmclOBt misc/OmHpqFBaR1K0lubiNv3kDoxkM0iyfoYz5LiWXDSX9DJAP+ZsCv+jI29Bf7utq gu506cUdlkERpOhroAcOsw7NopyGLNqZzK3VBmNPETE60sNSTmuKhlnc2G/lR+MSxT 0J1w5C3IjFt0bPRZvlUxSTJ1mWx25c/V6bI/sHW5J9mWba4gsXhNU5iGCBOjUaeowC AJozhMjqp6k2qslcm9FdOEHIqYGtItw/sFnNzruIf0/K1ESv7SZ4LV7NBz3FuikGI6 63f4SMEbCD/fw== Subject: [Edbrowse-dev] a JS centric design 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: Fri, 06 Nov 2015 19:50:47 -0000 So I was thinking, if I were to start all over again, what might I do differently? All those native methods and their side effects, very awkward, and they don't do the right thing all the time, and they are engine specific since they are in C, so have to be modified if we upgrade or switch js engines, and you still have to check a lot of js variables anyways because js doesn't always call those functions to do its thing. So ... What if there was a lot more js at the start, more prototypes, more functions, more js setters, and some specific edbrowse variables under window.eb$, variables that we can query after js has run. There would be almost no native methods, only one that I can think of and I'll get to that below. The real down side here is there are two ways to render text. First the one we already have which is based on the html tree. We have to keep that one because the user might run without js, for any number of reasons. The second, now, is to render the possibly modified js tree. Start at document.body and traverse childNodes depth first. This could build the text buffer directly, or, it could build a tree of nodes whence we call the first render routine above. It might be nice to leverage the preexisting render routine. Such would happen after every javascript call, push the button, modify a field with onchange code, make a different selection with onselect code, submit a form with onsubmit code, you get the idea. It looks a little painful relative to performance but in reality I don't think it makes any difference. You wouldn't run the update all that often, and web pages aren't that huge, and computers are pretty fast. Don't think performance matters, but the two different render routines, that's the down side. The up side is almost nothing is done through native methods and side effects passed back to the html process, everything is gleaned after js returns, and nothing is missed. Nothing gets lost in translation. The whole js tree, whatever it is, is rerendered. Let's look at some other nonrendering side effects. document.cookie could have an inbuilt setter to add the new cookie to a list of cookies to be processed when js returns, window.eb$.cookieList[], and the setter would also fold the new cookie into the cookie string that is returned by getter when document.cookie is queried. It's pretty easy, certainly easier than the native code we have today jseng-moz.cpp line 955. Perhaps not less code, but more maintainable. Here's something that seems like it still has to be native. document.location.href = "new web page". js doesn't keep going, it stops and edbrowse has to fetch a new web page. So whenever edbrowse has to take action, right now, not later, not delayed, not when js is finished but right now, that's a candidate for a native method. But here again, it doesn't have to be native, because js is suppose to stop. So set document.location.href like you normally would, set a jump flag in window.eb$.jumpNewLocation, and then throw an exception so that js stops. Same model, edbrowse checks everything after js returns. It sees the jump flag and goes to a new web page. Here's another one, document.forms[0].submit(). Run the onsubmit code first and if that's ok then set a jump flag in window.eb$.jumpFormSubmit0, and throw an exception so js stops. Still nothing is native. The only thing I've found so far that really must be native is that pesky innerHTML. It has to parse html and fold objects into the js tree now, before the next line of js runs, and, js does not stop, so we can't just throw an exception. I'm not going to translate the entire tidy system into js, so that will remain a C routine. innerHTML has to be native, and run the text through tidy, and our html-tidy.c or some variation thereof to make js nodes, and paste them into the tree, then it returns and js marches on. That's how the native method works today, and we could pretty much keep it as is. But that's it. Is it possible that if I were starting all over again with a js centric design that there would be only one native method, innerHTML? I'm not saying this is a better design, although part of me thinks it is, since there is less engine specific code, and each time we render the text buffer straight from the horse's mouth. But I don't know. And I'm certainly not planning any changes of this magnitude any time soon. We need to march towards 3.6.0 and stability. I just wanted to put this idea out there, in case I get hit by a bus tomorrow or something. Karl Dahlke