From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by hurricane.the-brannons.com (Postfix) with ESMTPS id E6140786FA for ; Sun, 28 Dec 2014 11:20:02 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so17638888wgg.35 for ; Sun, 28 Dec 2014 11:17:48 -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=3phLizmxZeBbK5ZwRSSxYlvwmMi/c2ikg2PGguChKkU=; b=ozeAvWOdA7cGojZs+9Ee1fAc6cmV44pP3pHzLfqMFAOpbOeeXiP8K0GtTb0ZIqgmfG vsjE+sad25UO1LQU6PS3ekVpahFPQDUT+Sg6kSAixC+quaaowYjieDmnhJbvVTjHFiYS r3qagFZNNHkPN92hxPd14UfSpXDwl1lB3LtBshA0sKeTrUKMU86fBMAe6WVFl6K9mmtE xrWVlhJcZvecpWWAl2zapfqKSKc4Fi1zh2zSMeetG5I7ULxThXLk9tJzyoTk6+wVw3wm Z1//SPyhzVbbdEY+22wW3i1nDzJ9c9EGAA3i6eSd+4CIcUaJUEMXdERWkw3L5KC6qzON N2Mg== X-Received: by 10.194.90.10 with SMTP id bs10mr103629407wjb.43.1419794267884; Sun, 28 Dec 2014 11:17:47 -0800 (PST) Received: from spoons.adamthompson.me.uk (8.3.3.3.0.d.e.f.f.f.2.d.4.2.2.0.5.9.a.d.8.a.b.f.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:fba8:da95:224:d2ff:fed0:3338]) by mx.google.com with ESMTPSA id j2sm47085899wjs.28.2014.12.28.11.17.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Dec 2014 11:17:46 -0800 (PST) Date: Sun, 28 Dec 2014 19:17:31 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20141228191731.GA16901@spoons.adamthompson.me.uk> References: <20141128134226.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="G4iJoqBmSsgzjUCe" Content-Disposition: inline In-Reply-To: <20141128134226.eklhad@comcast.net> User-Agent: Mutt/1.5.23 (2014-03-12) Cc: Edbrowse-dev@lists.the-brannons.com Subject: Re: [Edbrowse-dev] Tasks 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: Sun, 28 Dec 2014 19:20:03 -0000 --G4iJoqBmSsgzjUCe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 28, 2014 at 01:42:26PM -0500, Karl Dahlke wrote: > > though perhaps we want to be careful with duplicated efort. >=20 > Right, specialy since there's only three of us. > Would you like to look at v8? > So far none of us has a hello world program working. > There is one in src, that I got straight from google, > but it doesn't compile. >=20 > make js_hello_v8 Ok, I'll have a look at that. I'm also looking at any other js engines I can find (preferably not entangled with big browsers) but so far I'm not sure how mature any such engines are. > > I'd really like to get a proper DOM independant of js, > > then plug js into such a DOM. >=20 > Yes, yes, and yes. > I'm hoping that ebjs.c holds the api that will make this possible. > That was reason enough to move js into its own process, > though there are other advantages as well. > So ... are the prototypes in eb.p, from sourcefile ebjs.c, > enough to build a dom on top of? > If not then what else do we need? I think so from the js side of things. The problem is the fact that we need to have better support for parsing html into the initial structure before we load into js. I think we may also need some more tree traversal stuff inside the js side = of the DOM, and I'm not entirely clear how we handle if js makes wide-spread D= OM changes (like massive amounts of page elements created directly as DOM obje= cts). I think that support probably needs expanding and linking back to the brows= er's representation. We also need to load in style attributes as well as otherwise there's a good chance some js will blow up trying to perform some (to us unnecessar= y) visual effect and thus not get to some critical part of the code (i.e. onsu= bmit handlers). > > As for how much do we need to implement; > > if we want to have a browser that functions properly on the internet in= a few > > years then all of it. >=20 > Yes I suppose so. > It doesn't scare me, I just wish we had more resources, > like maybe an NFS grant to pay us to do it. More devs are usually helpful, certainly in this case. > > tracking through js is important, >=20 > I tried in particular to track through the js in the jquery library, > to see whether edbrowse is a mile away or ten thousand miles away > from supporting it, but I got rather overwhelmed. > It's still sitting in my to-do directory. If we sort the child node and parent node thing (not sure how far that got done), and probably get all the array types implemented (not just objects) then we'll be much closer. Throw in support for not just dynamicly altering selectors but also everything else in the DOM, and a function for searching through the DOM in various ways, and we'll have the page creation side sorted I think. > > make the callback given to curl support both operations, >=20 > Well of course. That's obviously a better design. Thank you. > I just put the data in memory or on disk, > according to some variables. Hopefully, though I'm sure I've missed something important in that logic, are threads or something involved? Gdb always says that curl spawns a new t= hread when it downloads, but I assume the curl_perform call blocks, so we s= hould be fine. > > Yeah, I'm wondering if we want to make that string file more c++ anyway > Anything that becomes common to edbrowse and edbrowse-js has to be C, > because edbrowse is entirely in C. > But making it common might not be worth the bother. > The routines are different in subtle ways. > The edbrowse copy calls setError() and such to report error conditions to= the user, > but in edbrowse-js those errors aren't as likely, and would be treated an= other way, > so it will probably be 400 lines of code that look similar in 2 places, > but aren't identical enough to put in common. Yeah... that should've read "the string handling in that file". I certainly didn't mean to suggest injecting c++ back into Edbrowse (we just spent a while removing it). However the js process has to be in c++ (unfortunately) and so we may as well use c++ stuff there. Cheers, Adam. --G4iJoqBmSsgzjUCe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUoFdLAAoJELZ22lNQBzHOmxYH/3Yd9BU4HXGvNmGO34OOAN/N CJWwlSlIpo3T9U3nje7CuYYjX4uluYZVMYh8u1M/bCfqXDzZt2HSPqcB2vaKoXR3 lh4Oo3aQ6FVBNbAGiA0+2OXyTe7z0Ul1ydMsgdJi+cAz1G86hKliG8LxGhzOM0xd 3hKhkUVCjfub49lhvIkPFubxIxchVt+ibFIH/0pKArWZdwsRxpwb5Tc3pOYTF5Hh 1UQ0WuZuZ4C/ywCq3aaIDQ2UeMWuRbzqiPiL5Icdij8NLageCdEBZd+6fsEF8pKU sp2e8tRdP4rNB0Eja9M07mp4Qz0GyKTqHrjJrH1Q2sajLAtYb/jnj3UaSGo9ork= =0oot -----END PGP SIGNATURE----- --G4iJoqBmSsgzjUCe--