From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by hurricane.the-brannons.com (Postfix) with ESMTP id CE25877AD6 for ; Sun, 22 Dec 2013 14:26:55 -0800 (PST) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta13.westchester.pa.mail.comcast.net with comcast id 4mLD1n0060vyq2s5DmSt4m; Sun, 22 Dec 2013 22:26:53 +0000 Received: from eklhad ([107.5.36.150]) by omta05.westchester.pa.mail.comcast.net with comcast id 4mSs1n00q3EMmQj3RmStyt; Sun, 22 Dec 2013 22:26:53 +0000 To: Edbrowse-dev@lists.the-brannons.com From: Karl Dahlke User-Agent: edbrowse/3.4.9 Date: Sun, 22 Dec 2013 17:26:49 -0500 Message-ID: <20131122172649.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=q20121106; t=1387751213; bh=0ilh75Z56hB82IR3c47NJ8ndfqiY7k/0SqUe1HNHfVQ=; h=Received:Received:To:From:Reply-to:Subject:Date:Message-ID: Mime-Version:Content-Type; b=Sx82+YR8kAcZd11oL+/JqGwXa8BExrwyUryVnO/iMsM+P90lNEqws8NRV7sjO4ViQ bPkSTbo/l30MVuFslwKiKsfkV+Ov6kQjZdO353OQRS1flUAnxiQzuTa7cdZYmdWyPU I87WP+lw1Yc/WFKobdwN0Flrpl4A8dvGph99rO35bcwDHnURslFNb4BtU8ZhQVNGch 8ZIj3rHwVpsNRYvcH3mi4hRA91nbymUmno2zpbjpX1YqXllCQc3OZkJv/3CjXMLFfz HMc4ruiChVVrtN2NZjM7qkBrONEqGZGH6gj5Z2+aPlQuBL6tk8vHZ8xUxtUtE08Epc OhI+AhjryinNg== Subject: [Edbrowse-dev] Javascript support X-BeenThere: edbrowse-dev@lists.the-brannons.com X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Karl Dahlke List-Id: Edbrowse Development List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Dec 2013 22:26:56 -0000 Hi Adam and all. It seems to me you are spot on, assumingf we want to take a few expedient steps, rather than a complete rewrite. When I think about string operations a complete rewrite is really tempting, but I know that would take to long. Our friend over at debian is tapping his foot. At this point I have to pat myself on the back, at least a little, since my design is based on encapsulation. I built jsdom.c and jsloc.c as a layer between edbrowse and the js engine, so that only these files need be touched. The rest of edbrowse knows nothing about javascript. So that's a couple thousand lines of code, not prohibitive. In fact, my original eb.h did not reference jsapi.h or anything javascript at all. I used void * for blind pointers to pass around js related structures. So an edbrowse buffer or context structure would contain a member void *js for all its javascript stuff, without knowing or caring what it meant. The semantics were all in js*.c. But at some point, and I don't remember when or why, #include was moved out of js*.c and into eb.h, so everyone could see and possibly muck with the javascript api. But still I don't think they do, not for the most part. It just means we can refer to jscontext * instead of void *, and the code is more readable, yet still I think it is all encapsulated in js*.c. The quick way, if there is such a thing, is to cp jsdom.c jsdom.C cp jslod.c jsloc.C Making the endings capital C instead of small c. Then call the c++ functions instead of the original functions. We can do this before the upgrade, since moz185 has the c++ interface. The new calls will likely return a pointer to an object, not a structure, but object structure it's all the same. I can't pass that around amonst the other c functions in edbrowse. In other words, go back to void * as it was before. Keep all the js headers and classes in js*.C, as it was before. Then when you can compile cc -c js*.C (that's capital C) switch the Makefile over to use those files and not the original js*.c, which we'll keep around for a while until we know what we're doing. So the first step might be to see if we canpt put #include back into jsdom.c and jsloc.c, and out of eb.h as it once was. Then make files with capital C instead of small c. gcc does the right thing based on the suffix. Then access the new api, which is probably not radically different from the old just creates objects and calls object methods instead of functions. I might be oversimplifying this terribly, I really don't know. I have bookmarked the documentation for all the smjs functions, is this updated to reflect the new c++ interface? And finally the question is who has time for all this? I don't know but I hope someone does, edbrowse is too valuable to die on the vine. I might, depending on how my life goes, but the first thing I have to do is learn c++, which I have religiously avoided for 30 years. Truly, for 30 years. Maybe it's time. But if any of you know c++ better than me, which wouldn't be hard to do, then you're a step ahead. Karl Dahlke