From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out.smtp-auth.no-ip.com (out.smtp-auth.no-ip.com [8.23.224.60]) by hurricane.the-brannons.com (Postfix) with ESMTPS id 2E29D77B87 for ; Sat, 19 Dec 2015 15:40:31 -0800 (PST) X-No-IP: carhart.net@noip-smtp X-Report-Spam-To: abuse@no-ip.com Received: from carhart.net (unknown [99.52.200.227]) (Authenticated sender: carhart.net@noip-smtp) by smtp-auth.no-ip.com (Postfix) with ESMTPA id C232C400952; Sat, 19 Dec 2015 15:40:33 -0800 (PST) Received: from carhart.net (localhost [127.0.0.1]) by carhart.net (8.13.8/8.13.8) with ESMTP id tBJNeWIZ015052; Sat, 19 Dec 2015 15:40:33 -0800 Received: from localhost (kevin@localhost) by carhart.net (8.13.8/8.13.8/Submit) with ESMTP id tBJNeWRs015035; Sat, 19 Dec 2015 15:40:32 -0800 Date: Sat, 19 Dec 2015 15:40:32 -0800 (PST) From: Kevin Carhart To: Adam Thompson cc: Chris Brannon , Edbrowse-dev@lists.the-brannons.com In-Reply-To: <20151218141232.GB2770@122oven.adamthompson.me.uk> Message-ID: References: <20151217134608.GA4216@acer.attlocal.net> <87vb7xi0vd.fsf@mushroom.localdomain> <20151117103105.eklhad@comcast.net> <87r3ilhwij.fsf@mushroom.localdomain> <20151218141232.GB2770@122oven.adamthompson.me.uk> User-Agent: Alpine 2.03 (LRH 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [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: Sat, 19 Dec 2015 23:40:31 -0000 > > 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 at least > a basic XHR object which don't require rewriting (or duplicating using an async > design) Edbrowse's comms layer? 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. Currently in startwindow.js we have a stub of an XMLHttpRequest: XMLHttpRequest = function(){ this.headers = {}; this.responseHeaders = {}; this.aborted = false;//non-standard }; But off in my not-yet-submitted code, I have an implementation of open: open: function(method, url, async, user, password){ 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! It is not intended for the robust edbrowse in its current form. 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) 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. Maybe the incremental steps of which you speak would be to do some of this, only well. :) Kevin This duplicates http.c, but I didn't know how to get back to the C code. And of the send method. And for the HTTP action, I just wrote something that works like other native implementations of a javascript keyword. It just accepts the appropriate parameters and calls curl. And of the send method, where all I did was redundantly bring over a routine that can call curl, into jseng-moz. > > Cheers, > Adam. > -------- Kevin Carhart * 415 225 5306 * The Ten Ninety Nihilists