I think Randy makes a great point here. Maybe 2 things are being jammed into one and they need to be split.
Goal 1, provide url's that are proxied but allow the page to interact with it's home server as if they were local. Thus standard url's get replaced with <proxy_url>?url=<original_url> for all interactions. Goal 2, provide an API that simplifies the XHR calls, provides batching, and OAuth This is for developers that don't already have a JS API to use and would otherwise have to use the XMLHttpRequest directly. The point is they are two different goals. Shouldn't they be neatly divided? In my mind, the ideal situation would be to walk up to OpenSocial with an existing ajax API and simply point at the Shindig Proxy and everything ought to just work. For example, could I use the gadget.getProxyUrl() call then pass that url to dojo.xhr() and have everything work as if I was hitting the server directly? On Tue, Nov 17, 2009 at 9:43 AM, Randy Hudson <huds...@us.ibm.com> wrote: > I'd like to suggest that the default behavior be the same as > XMLHttpRequest: > > "If the redirect does not violate security (it is same origin for > instance), infinite loop precautions, and the scheme is supported, > transparently follow the redirect" > > I think the only optional setting needed would be to not follow redirects, > but even that isn't supported today by XMLHttpRequest, so how important is > having such a setting. I'm not sure if the goal of makeRequest should be > to provide some fancy new service (I'm over-exaggerating, but it's a > slippery slope). If something more complex is needed by a Social App, it > can always host the service itself and use makeRequest to invoke such > services. After all, isn't that the point of makeRequest?! > > Thanks for Google groups link. > > --Randy Hudson > > > > > > From: > John Hjelmstad <fa...@google.com> > To: > shindig-dev@incubator.apache.org > Date: > 11/16/2009 05:34 PM > Subject: > Re: 3xx shouldn't be classified as errors in gadgets.io.makeRequest > > > > @see > http://groups.google.com/group/opensocial-and-gadgets-spec/browse_thread/thread/716acaa66ceba244 > > > Seems to me that adding a FOLLOW_REDIRECTS option to makeRequest's params > would make sense, assuming all security concerns are resolved. > > --j > > On Mon, Nov 16, 2009 at 2:28 PM, Randy Hudson <huds...@us.ibm.com> wrote: > >> It would be great if developing/migrating a Web UI for use as a Gadget >> imposed the smallest possible "penalty". For the most part, makeRequest >> is the alternative to what would have been done via XmlHttpRequest in > the >> original, "standalone" version of the same web app. To me, this > suggests >> that gadgets.io.makeRequest should emulate the behavior of > XmlHttpRequest >> as much as possible, including following redirects (to locations at the >> same host). >> >> Developers migrating existing apps to run as a gadget may choose to >> wrapper XmlHttpRequest (or existing equivalent, e.g. dojo.xhr) instead > of >> changing all of their code that makes such calls. This approach also >> makes it possible to reuse code in both remote (i.e. in a gadget >> container) and local contexts. >> >> If makeRequest doesn't follow redirects, even developers starting from >> scratch would be encouraged to wrapper makeRequest with their own > utility. >> I wouldn't want to write javascript to follow redirects while detecting >> redirect cycles every time I do XHR. >> >> -Randy Hudson >> >> >> >> From: >> John Hjelmstad <johnfa...@gmail.com> >> To: >> johnfa...@gmail.com, shindig.remai...@gmail.com, bea...@google.com, >> jon.weyga...@gmail.com >> Date: >> 11/11/2009 04:33 PM >> Subject: >> Re: 3xx shouldn't be classified as errors in gadgets.io.makeRequest >> >> >> >> On Wed, Nov 11, 2009 at 12:54 PM, <jon.weyga...@gmail.com> wrote: >> >> > Is it clear from the OS specification that redirects should (or should >> > not be) followed? >> > >> >> Not too sure... >> >> >> > >> > Would this be something that we would want to add, along with perhaps > a >> > parameter to turn it on/off? >> >> >> ...but I'd be in favor of this. >> >> >> > >> > >> > http://codereview.appspot.com/152070 >> > >> >> > > -- David S Boyer mang...@gmail.com 703.499.8728(h) 703.408.5395(m)
