[untog]

But you can't.

If you are in a client browser (any client browser, no matter how old) and try to do HTTP.get('http://www.google.com') it will fail because of CORS restrictions. If you do that on the server or in a native app, it will succeed (because they do not have CORS restrictions).

[rational-future]

Yes, we can :)

Working around CORS is just a matter of server configuration. With the same API you only fix the servers, with different APIs you have to fix both the servers and the code.

[untog]

Sure, if you control the server. I guess these Meteor packages will only be useful in those contexts. But what if I want to use the Twitter API, for example?

[ef4]

I'm pretty sure their answer is: we can automatically proxy through the meteor server to twitter or anywhere else.

[rational-future]

I believe Twitter is trying to kill their API, hence no CORS or JSONP.

[joesb]

The point is that only HTTP.get() inside browser require CORS to be enabled on the server side. On non-browser environment, HTTP.get() can open any cross site web request.

[rational-future]

Well the point is any other API will face the same restrictions in the browser. It isn't something JavaScript code can fix directly. If you need to call external services from the browser (and not everybody does), the isobuild APIs certainly don't make the situation worse.

Also HTTP.get() may be smart enough to detect cross-domain call failure and try to automatically proxy the call. Meteor has a server-side component that can act as a proxy.

[catshirt]

the code doesn't fail, the response just differs by client. for the purposes of your example, the "server" is a actually a client. and that's not a problem for the package manager to solve.

if anything, isn't this a great argument for a client/server package manager? you could write a library that knows to use and create a proxy if a specific client type tries to fetch cross domain.