New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Javascript XMLHttpRequest Client implementation #172

Merged
merged 4 commits into from Sep 8, 2014

Conversation

Projects
None yet
3 participants
@andrewray
Contributor

andrewray commented Sep 7, 2014

This is an attempt to use XMLHttpRequest to make client HTTP calls from javascript programs via cohttp.

It has been lightly tested with ocaml-github where it is able to query the github API. Much still to be tested but perhaps this could be useful.

@@ -0,0 +1,41 @@
(*
* Copyright (c) 2012-2013 Anil Madhavapeddy <anil@recoil.org>

This comment has been minimized.

@avsm

avsm Sep 7, 2014

Member

should be copyright you here

len : int;
}
module String_io = struct

This comment has been minimized.

@avsm

avsm Sep 7, 2014

Member

nice, I'll pull this out into so that we can have a StringCohttp pre-applied as well.

@avsm

This comment has been minimized.

Member

avsm commented Sep 7, 2014

I've removed the Lwt from the String IO implementation (using type 'a io = 'a) and moved it into Cohttp directly so other backends can use it if they choose.

In #173

@avsm

This comment has been minimized.

Member

avsm commented Sep 7, 2014

Would you have a simple test case for the JS backend?

@andrewray

This comment has been minimized.

Contributor

andrewray commented Sep 7, 2014

Does it need to be automated? I can provide a very simple test case you could run manually from a browser and, say, do a simple github query.

Automated is a bit harder. I think you can run js_of_ocaml on node.js (or it's been talked about anyway) in which case there are XHR implementations for it which may work.

@avsm

This comment has been minimized.

Member

avsm commented Sep 7, 2014

Manual is just fine!

On 7 Sep 2014, at 13:03, Andrew Ray notifications@github.com wrote:

Does it need to be automated? I can provide a very simple test case you could run manually from a browser and, say, do a simple github query.

Automated is a bit harder. I think you can run js_of_ocaml on node.js (or it's been talked about anyway) in which case there are XHR implementations for it which may work.


Reply to this email directly or view it on GitHub.

@andrewray

This comment has been minimized.

Contributor

andrewray commented Sep 7, 2014

So here's a simple test using Cohttp_lwt_xhr to query a users github repositories and display the resulting JSON.

Note; requires Yojson to pretty print the result which may not be a dependency you want.

@avsm

This comment has been minimized.

Member

avsm commented Sep 7, 2014

Ta! Ezjsonm is probably better since it doesn't do any obj magic -- I'll fix it up locally

On 7 Sep 2014, at 15:04, Andrew Ray notifications@github.com wrote:

So here's a simple test using Cohttp_lwt_xhr to query a users github repositories and display the resulting JSON.

Note; requires Yojson to pretty print the result which may not be a dependency you want.


Reply to this email directly or view it on GitHub.

@andrewray

This comment has been minimized.

Contributor

andrewray commented Sep 7, 2014

I'm not convinced it does - I think that was just atdgen. I was more thinking about having a dependency thats not in cohttp itself.

Actually I think theres some json stringify magic in javascript which would do this as well.

@mor1

This comment has been minimized.

Member

mor1 commented Sep 7, 2014

ityw JSON.stringify(...)

On 7 September 2014 15:16, Andrew Ray notifications@github.com wrote:

I'm not convinced it does - I think that was just atdgen. I was more
thinking about having a dependency thats not in cohttp itself.

Actually I think theres some json stringify magic in javascript which
would do this as well.

Reply to this email directly or view it on GitHub
#172 (comment).

Richard Mortier
mort@cantab.net

@andrewray

This comment has been minimized.

Contributor

andrewray commented Sep 7, 2014

I think this version is a bit better. It also now prints the response headers which I think will be useful for debugging.

Some stuff still to do;

  • Use async XMLHttpRequest request (important)
  • May need to filter out some headers which are not allowed in browsers (on chrome they leave warnings in the log, other browsers may not be so forgiving)

@avsm avsm merged commit e73ff3f into mirage:master Sep 8, 2014

1 check passed

continuous-integration/travis-ci The Travis CI build passed
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment