Fw: XHR in js libraries in a gadget
Dan Dumont
----- Forwarded by Dan Dumont/Westford/IBM on 01/18/2012 03:49 PM -----
From: Dan Dumont/Westford/IBM
To: d...@shindig.apache.org,
Date: 01/18/2012 01:46 PM
Subject: Re: XHR in js libraries in a gadget
I just found the "shindig.xhrwrapper" feature.
I'm wondering if it might be a good idea to push this up into the spec and in the OS Api.
It would help these efforts (dojo, jquery, etc adoption) if any gadget could request an osapi.xmlhttprequest feature that would provide this factory in any os environment.
Thoughts?
From: Dan Dumont/Westford/IBM@Lotus
To: d...@shindig.apache.org,
Date: 01/06/2012 03:42 PM
Subject: XHR in js libraries in a gadget
I had this quick conversation with John Hjelmstad today:
me:
So we've had people ask us about using dojo in os gadgets
I think it's something that you guys may run into when/if you start really
pushing on the appdev gadget story
John: indeed
me: I'm going to be working on a patch to dojo to enhance the xhr module
to prefer the os impl instead of the existing one
was wondering if there are any jquery committers at google that could
mirror my efforts
John: I presume you found a conflict of some kind?
you know, I just might
One of my reports has contributed, though I'm not sure if he's got
committer access to the repr.
repo
me: well dojo xhr presumes to do all of the xhr itself... the osapi
impl has some quirks in how the proxy url is used (or rpc instead of xhr)
that make dojo unable to cope with it
John: that makes sense
me: I'm pretty sure jquery has the same issue
Just tossing this out there as an FYI about the problem and to let anyone
who has another favorite js lib (prototype, etc...) know so that they can
push the effort in that project.
Ryan Baxter
your patch back to DOJO?
On Jan 18, 3:49 pm, "Dan Dumont" <ddum...@us.ibm.com> wrote:
> From the shindig dev list:
>
> ----- Forwarded by Dan Dumont/Westford/IBM on 01/18/2012 03:49 PM -----
>
> From: Dan Dumont/Westford/IBM
> To: d...@shindig.apache.org,
> Date: 01/18/2012 01:46 PM
> Subject: Re: XHR in js libraries in a gadget
>
>
> I'm wondering if it might be a good idea to push this up into the spec and
> in the OS Api.
> It would help these efforts (dojo, jquery, etc adoption) if any gadget
> could request an osapi.xmlhttprequest feature that would provide this
> factory in any os environment.
>
> Thoughts?
>
> From: Dan Dumont/Westford/IBM@Lotus
> To: d...@shindig.apache.org,
> Date: 01/06/2012 03:42 PM
> Subject: XHR in js libraries in a gadget
>
Dan Dumont
I have an example that uses osapi.http.get rather than makerequest, but either should work.
If this were an OS specced feature it would be more likely to be supported by any OS container.
You received this message because you are subscribed to the Google Groups "OpenSocial and Gadgets Specification Discussion" group.
To post to this group, send email to opensocial-an...@googlegroups.com.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/opensocial-and-gadgets-spec?hl=en.
Ryan Baxter
It just seems unnecessary to me since we already have the osapi.http
APIs which essentially wrap the xhr, and now we are exposing it. In
either case, you will be checking to see if the "xhr wrapper" is
already there, but I think you concern is that you want your changes
to dojo to work regardless of the implementation, which I am certainly
in favor with.
So in Dojo do they declare a global xhr object, and you want to set
that object to an OpenSocial object?
Have you looked to see if JQuery and other JS frameworks would also be
able to leverage this?
On Jan 23, 9:01 am, "Dan Dumont" <ddum...@us.ibm.com> wrote:
> Dojo would rather not include the code to wrap a fake xmlhttprequest
> object, if it were a shindig feature that dojo could detect and use, the
> code change for support would be very minimal.
> I have an example that uses osapi.http.get rather than makerequest, but
> either should work.
>
> If this were an OS specced feature it would be more likely to be supported
> by any OS container.
>
> To: OpenSocial and Gadgets Specification Discussion
> <opensocial-an...@googlegroups.com>,
> Date: 01/21/2012 02:01 PM
> Subject: [osgs] Re: Fw: XHR in js libraries in a gadget
> Sent by: opensocial-an...@googlegroups.com
>
Henry Saputra
technology to send asynchronous request. If one day we could use
websocket to allow continuous/push connection then we need to also
expose it to the spec.
- Henry
Dan Dumont
Applications written on top of a js library like dojo, jquery, prototype, etc... are, under the covers, using an XmlHttpRequest interface (browser dependent) to do XHR.
This means that most of the applications that rely on XHR will fail out of the box. Rewriting the entire xhr mechanism for your app can be painful, so I think it's worth throwing some bait out there for those js libraries to get some baseline support for OpenSocial gadget environments.
I'm not suggesting that we don't insist that the supported and preferred apis are osapi.http.* and gadgets.makeRequest, I'm just saying that some baseline support for easy integration into js libraries would go a long way towards getting people to port their apps to gadgets.
The existing feature that I called out is a shindig only feature and provides an XmlHttpRequest object that internally uses makeRequest to do the xhr.
Dojo, for example, would easily be modified with a very small code change to detect and use this xhr object instead of the native browser one. I'm also pushing that people involved in other js libraries like jquery and prototype get this support in as well. Having a feature in the OS server means that these libraries can rely on it being there. Smaller code changes for support like this are preferable, and make the support much more likely to get in. It also makes monkey patch work-arounds a lot easier to handle for older versions of those libraries.
If we can move this to a OS spec feature, I think it will help us get more people to port their applications to gadgets. Though, again, we should call out that the preferred xhr apis are the osapi.http and makerequest apis.
Ryan Baxter
one overarching use case.
If an application developer has an existing application which uses
Dojo, JQuery, Prototype, etc and they want to reuse that app inside a
gadget they run into a problem because their application now needs to
use the underlying proxy in order to make any XHR request. To get
broader adoption of OpenSocial developers want to be able to leverage
as much of their existing app as possible, having to rewrite their
code to use osapi.http or makeruest is painful...
Tim Wintle
> So in Dojo do they declare a global xhr object, and you want to set
> that object to an OpenSocial object?
>
> Have you looked to see if JQuery and other JS frameworks would also be
> able to leverage this?
jQuery does allow you to pass in an XMLHTTPRequest factory function when
using jQuery.ajax(). I'm not sure about the derived ajax methods, but
they would be simple enough for a user to stub with modified versions.
Tim
Ciancetta, Jesse E.
I was thinking about this more this morning and was actually going to suggest considering this type of model vs. trying to get the different frameworks to agree to look for a particular object in the DOM during their initialization. I think if I were on the framework side I'd be very resistant to checking for the existence of a particular object at initialization time -- it just seems too arbitrary and specific to me (what if someone else came along and had a good reason to prefer they look for some other object etc). But I think I'd be open to adding hooks to do something like what it sounds like jquery supports by passing an XHR factory function.
That would put a bit more of the burden for supporting different frameworks back on the shindig side, but that actually seems more appropriate to me. So we'd need to define one generic feature which builds the XHR wrapper over osapi.http (and it sounds like that already exists) and then we'd need to build a framework-specific feature which depended on the generic wrapper and added the required framework-specific initialization for each framework we wanted to support.
Although thinking through it a bit more... If the framework-specific initialization to override XHR was part of a one-time initialization function then we couldn't really call it from our feature since the gadget may need to specify additional initialization parameters of its own... So maybe then the framework-specific feature would just do whatever legwork was required to get as close as we can and then leave it up to the gadget developer to connect the last dots? So in the case of jquery -- maybe we could define and make available the XHR factory function but leave it to the developer to do the last bits of hooking it up (just using this as an example -- if it's possible to do all of the work ourselves without causing any problems that would of course be fine too).
>Tim
>
>
>--
>You received this message because you are subscribed to the Google Groups
>"OpenSocial and Gadgets Specification Discussion" group.
>To post to this group, send email to opensocial-and-gadgets-
>sp...@googlegroups.com.
>To unsubscribe from this group, send email to opensocial-and-gadgets-
>spec+uns...@googlegroups.com.
Dan Dumont
Some, or all, of the library might be loaded in stages. Shindig cannot really do more than provide the xhr factory.
I think it's fine to let the applications, or the libraries themselves connect the dots.
I don't really see why it would be a problem to sniff for the os feature xhr factory. Currently, these libraries already try to sniff for the appropriate native xhr factory, the os one isn't much different, in that it's currently necessary to use it if you want to do xhr in that environment. However, I guess it would be up to the individual library (or the application to monkey-patch the library) to bake the support in. I just think at the very least, OS should have a public feature to offer this support, from our end I think that's all we can do.
To unsubscribe from this group, send email to opensocial-and-gadg...@googlegroups.com.
For more options, visit this group at