From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) by hurricane.the-brannons.com (Postfix) with ESMTPS id BBDE377B87 for ; Mon, 21 Dec 2015 15:29:43 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id l126so88161989wml.1 for ; Mon, 21 Dec 2015 15:29:51 -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=7B2eG/mHM8mV4e/ALQ59ETE4f37lf0rR/EUgoo+BpQs=; b=CEVnoSNtcJbuoKKKwoXzarpYTtRV45zdJndvIczDxqg91O5scGHr+kQwnRSN2pMA+C TdQO3OVZf3HV4cxoe5oQAm8Xuan8zLJuz+WpPNJP3ijhlNEPHbwkU89TJsmiRTH1HG+E QLw45IWvsFYrimtXgw7Fxrvi9cZrlxQ2S1pyvrc7eJuhfQalnYAuBBQicS6z+zXXhves a8vBM25nIr4loWBWMD38rN0Rf/qlSqog4ALfsHK7xposhGepefaw6ogsNX6Nnb3ut9Rs 6yB/GY3SYB2z3NUmU7zVl4esI+JDNIJ/PmbexBZELRKUA+lIv1t09hW2r3JXtnj2bOhk GDJA== X-Received: by 10.194.2.168 with SMTP id 8mr27619936wjv.66.1450740589855; Mon, 21 Dec 2015 15:29:49 -0800 (PST) Received: from hob.adamthompson.me.uk (214.75.2.81.in-addr.arpa. [81.2.75.214]) by smtp.gmail.com with ESMTPSA id bh6sm30285489wjb.0.2015.12.21.15.29.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Dec 2015 15:29:48 -0800 (PST) Date: Mon, 21 Dec 2015 23:29:42 +0000 From: Adam Thompson To: Kevin Carhart Cc: Chris Brannon , Edbrowse-dev@lists.the-brannons.com Message-ID: <20151221232942.GA5604@hob.adamthompson.me.uk> References: <20151217134608.GA4216@acer.attlocal.net> <87vb7xi0vd.fsf@mushroom.localdomain> <20151117103105.eklhad@comcast.net> <87r3ilhwij.fsf@mushroom.localdomain> <20151218141232.GB2770@122oven.adamthompson.me.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [Edbrowse-dev] XHR 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 23:29:44 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 19, 2015 at 03:40:32PM -0800, Kevin Carhart wrote: > > > >I don't personally have an account but, > >since I've ended up with more time than I expected, > >I'm beginning to think that getting a somewhat functional XHR object is = more > >pressing than a js engine switch. > >As such, are there any incremental steps we can take which will get us a= t least > >a basic XHR object which don't require rewriting (or duplicating using a= n async > >design) Edbrowse's comms layer? >=20 > I have some code, but I'm not sure if you will be able > to use it or not. I managed to get a little further with > some sites by giving it a crude S-JAX. Ok, that sounds like something at least. > Currently in startwindow.js we have a stub of an XMLHttpRequest: >=20 > XMLHttpRequest =3D function(){ > this.headers =3D {}; > this.responseHeaders =3D {}; > this.aborted =3D false;//non-standard > }; >=20 > But off in my not-yet-submitted code, I have an > implementation of open: >=20 > open: function(method, url, async, user, password){ >=20 > And also of 'send'. To do the HTTP, I hooked it up with a > simple curl call back in the C++ file. It accepts > parameters, it runs a request-response, and returns > the output to a javascript variable. Probably insecure! Rather than a js variable I think it should produce some sort of response object, but other than that I think that's how it's supposed to work, not just splicing things directly into DOM. > It is not intended for the robust edbrowse in its > current form. I don't think we're intending to do another release for a little while, so if it isn't robust at the moment we can battle-test and fix it prior to = that point. > So it's a preliminary stab, which doesn't yet have > two massive things, (a) to be asynchronous and > (b) bringing your response back to the edbrowse > tree (if needed - I thought maybe the process of > how to splice the new XHR response text back into > the tree on the JS side would cover it, because > then our existing side effects would take it back > to the edbrowse tree) You're correct I think in that we should suck this back or discard it depen= ding on the js. This should be existing functionality. > All it is right now is a side HTTP getter which > does not work as a continuous DOM splicer, but > executes a second GET/POST, puts the resulting > "raw material" in a variable and leaves it up > to you to do something with it. Sounds good. > Maybe the incremental steps of which you speak > would be to do some of this, only well. :) Sounds fine, perhaps we can alter it to use http.c rather than curl directl= y, using some of the background downloading (but into memory via temp files or some such magic) to do the async part almost "for free". I'm not sure though. It's definitely something we need to look at. Then we just need to add OPTION requests and CORS support (and probably some more async plumbing) and we'll have something like an AJAX feature. Anyway, I think it'd be useful to clean up and submit what you've got so we= can see where we are. Cheers, Adam. --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWeItmAAoJELZ22lNQBzHOGP8IAMWZx5II5x3SZT8i7S6ZJkai a3pO/uKeH/zGZKNchvUwXxaSfOiX8yT4VXmbBVjLzPPQWBPpVjZse7D2EfvTyJ4w gLQD4CM610Ta0P4V7YpMLArGcSXlKMXWzoBSgAUdJEBVRi1t1rt+5f6bAL5dmB87 OzTP8426zbwHxM5CJZVtteVDRUfZ/Y2VgbaBHiN74YlSxEiCSsnnzJnAbaaT9fYI ZUQ2WGmzrf33Ej2J5p9S/Kd2Ag1M90eYJjYNACwLTtUXYdypzyp197IVbVOoqdaH eSGFb5m9T62TYUiZeaSe5RsJqixoDvx36mgU9tmxwdMhcIc8csBCPaSWIhasnHM= =cI0R -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD--