From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 838DB78E1B for ; Sun, 28 Dec 2014 08:00:01 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id k14so17506938wgh.29 for ; Sun, 28 Dec 2014 07:57:46 -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=1FoZG+RSmPiT1fD/O+IpnF/7LF4xVxWs9/GyBudTf38=; b=DYLSmNrIOngaiuCVUjyZoA09s9WWqxRbgULCSXmG9Kg9gyU1WoZiHnqUWMQcHa5UKR u3zLpFeIITFXPVE3vvahr2E4hmwnSiyv/T0DMBqKpE4X/DIOuLtUNopOqhBeOQ1edkYI kzrWTjEgxfaFGA7XZGSW5Vq4Af1CEzaRw6zyuMv60QxW5Ni+FBT8gM5DpNBd0vA4bhlF ZYweynIidLJuBHyGHGO3UicVtxeCKcIcqdF+fpuPJoVSyCVI/5jxpJyr3i3qjpXTrQb7 ZDBffLaaTeaHnkohBkBbjEsEwVyil5AejOfzKvwOp74hv5Bn+NhnYiwXNwru4JNF7YrV fc+w== X-Received: by 10.194.77.73 with SMTP id q9mr77070063wjw.24.1419782266208; Sun, 28 Dec 2014 07:57:46 -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 cy3sm1549782wjb.22.2014.12.28.07.57.44 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Dec 2014 07:57:45 -0800 (PST) Date: Sun, 28 Dec 2014 15:57:42 +0000 From: Adam Thompson To: Karl Dahlke Message-ID: <20141228155742.GB17072@spoons.adamthompson.me.uk> References: <20141126221739.eklhad@comcast.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i9LlY+UWpKt15+FH" Content-Disposition: inline In-Reply-To: <20141126221739.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 16:00:02 -0000 --i9LlY+UWpKt15+FH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 26, 2014 at 10:17:39PM -0500, Karl Dahlke wrote: > 1. Research into v8 or perhaps other js engines. > Just play with it, hello world, what can it do, > is it better or worse than moz, perhaps rewrite jseng.cpp in it if you > really want to dive in. Ok, this seems like something everyone can look at, though perhaps we want to be careful with duplicated efort. Has anyone successfully compiled anything against v8 yet? > 2. Is there any open source that would help us with DOM? > I thought we might steal from Chrome, which would play better with v8, > but I don't know if any dom software can reasonably be extracted from the= whole. I think we've been down the route of "playing nicely" with a js implementation already. I'd really like to get a proper DOM independant of js, then plug js into such a DOM. That changes the research perspective (at least in my mind) to an open source html parsing library, then writing code to convert that representation into a dynamic DOM=20 alterable via js. That also allows us to separate the parsing and rendering code which imho w= ould be a good thing. > 3. How does dom really work anyways? > Is there a book or tutorial that actually tells us what we have to implem= ent? Yeah, the w3c have a bunch of DOM specs, most of which assume we've already parsed the html into a tree (which people also refer to as a DOM), hence why we need to separate the parsing and rendering code (we've thankfully already separated the js). > 4. Fork off a copy of edbrowse and download files in the background, > as described in my earlier email. Ok, I think this's already being handled. > 5. Implement imap. A lot of people want this. > Many more would use it for mail if it had imap, > and curl supports imap, > so I don't think this would be as hard as it first appears. Unfortunately I don't use edbrowse's mail support so I can't really=20 help with this. > 6. How are we going to approach frames and iframes. > Today I turn them into hyperlinks to the web pages, > but *every* other browser puts all the pages together > into oneseamless whole. > We should probably do that too. > Then buffers and web pages don't corresponds 1 for 1 any more. > Lines 237 through 451 might be this page, > and 452 to 989 that page, and so on. Hmmm, not sure how to handle this either. Perhaps we could load the pages, but keep them in another buffer, with cross-buffer js support, or some sort of frame delimiters... I don't k= now. > 7. What happens when javascript accesses variables in other documents. > This can be done through frames. > In the mozilla world, those variables are in another compartments. > Doesn't that cause js to blow up? > Or at least not to see those variables? > Or is everything in firefox in one compartment, > but that can't be right either because each compartment > has one global window object. > Maybe interwindow communication doesn't happen enough for us to worry abo= ut, > and is usually done for visual effects anyways. Yes we *do* need to worry about this. Basically you can do all sorts of cross-compartment calls in mozjs, I don't really know how to implement it, but I know it can be done. Also, they have a splitwindow object to handle global and non-global window components, but even the mozilla devs tell people this is intended as a firefox-only feature. Again, I think we've got a very different design from these browsers and need to think slightly differently (taking lessons from = them where we can of course). > 8. What is ajax and jquery and all those, and how much of that > do we have to implement? Ajax has a w3c spec and tutorials, jquery is a library, all be it a popular one. If we fix our DOM we'll get a bunch of jquery for free, and if we do ajax we'll get most of the rest (we possibly need json a= s well). As for how much do we need to implement; if we want to have a browser that functions properly on the internet in a f= ew years then all of it. > 9. Find the most common websites, and trace through the js, slowly and pa= infully, > to see what we really need to do. > This is market driven, the 100 most used websites, > and make edbrowse work for those. > Given our limited resources, we might have to proceed this way, > rather then doing it all. I'm not too sure about this approach. I think at this stage we'd do better to get a cleaner, more maintainable design and work from there. If we make sure we keep up with bug tracking and releases then I think the = top 100 websites'll appear enough on our bugs list to eventually end up fixed. This also allows us to fix the more fundimental problems, like our DOM, without getting distracted by trying to hack on an existing design. > I've tried to track through js to see where edbrowse fails and why, > and it's a terribly slow and frustrating process, > especially if the js has been deliberately crapized. > I think we really need to do some of this, but I rarely have the patience > to actually do it. Agreed, tracking through js is important, and will become more so if we decide to revise the parsing, rendering and js dom logic. What we also need to get better at is turning our findings into jsrt tests. Cheers, Adam. --i9LlY+UWpKt15+FH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUoCh2AAoJELZ22lNQBzHO0sMIAI0fvi2sTmZXgrEiJy9fuGN6 5SnoYcbtTzVFzLjnGnX8BM+ibVK89yD6VP8YDZ8ImfuFttWvP4KcGYOEax6ZH/YE i82ci0pcHei3a0H5kFS/95n0AVUgbEC8aul+b1QHXC3mnyW7wcxhW6Xlt9RaKjVY pj0YYumASZ6SDrr/W5wzACf7GHaD8Y1g4UKPWiFx8oUGESizy/4BlF3oCulESN6x epiEcOX8j5yTAn09tn2Opdb7r4dRHDoR3vUwYOvIOgK+m3+LghROoILRg6rf9Exa Yj91ky25/ymo6n6imwhwf6VmA8q57O0ZebQrOslBzc67jrZjdgdoQmMxLKeL6BA= =b4aV -----END PGP SIGNATURE----- --i9LlY+UWpKt15+FH--