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 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.

Ok, that sounds like something at least.

> 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!

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 depending 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 directly,
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.