[dojo-contributors] Flash Cross-Site Access Plugin

Kris Zyp kzyp at dojotoolkit.org
Thu Oct 9 12:25:03 EDT 2008

I was wondering if anyone had any suggestions or if there was a specific
policy on what should be included in Dojo...

Dojo 1.2 included a new registry for providing alternate XHR "plugins"
that could operate in lieu of the standard browser XHR mechanism to
provide cross-site requesting capabilities using the standard call-site
syntax of dojo.xhr(). The dojox.io.xhrPlugins module works done by
explicitly adding a XHR handlers and the URLs they cover (no magic
here), and several of these handlers are provided for different
cross-site techniques. One technique that I didn't include was using
Flash for cross-site requests. Recenty, the author of a JavaScript-Flash
bridge/library (http://flxhr.flensed.com/) contacted me about getting
his cross-site Flash/JavaScript library working as an XHR plugin for
Dojo, so I gave him a little help and he put together a plugin for

So back to the question, should this plugin be included in dojox.io
(assuming CLA and everything)? The plugin is dependent on the third
party library. That library could be included (still assuming correct
licensing), but I assume we wouldn't want to do that since it has it's
own global namespace. I could just include the plugin, but I am guessing
that might be frustrating to users to find that they can't use the
plugin without downloading the other library. Anyway, I am assuming the
best course would be to simply include a note in the dojox.io.xhrPlugins
documentation indicating that there is a Flash/JavaScript library
available for use with servers that support Flash's cross domain
mechanism and provide a link to it.

And in case you want to see it, here is the demo he created (as well as
our discussion further below):

    Oops, that link should be:



    From: "Getify Solutions, Inc." <getify at gmail.com>
    Sent: Thursday, October 09, 2008 11:11 AM
    To: "Kris Zyp" <kris at sitepen.com>
    Subject: flXHRproxy modified

>     So, taking your questions about namespaces into account, I've done
>     some optimization and reorganization of the original bit of code I
>     sent you for this plugin.  I'm much happier with how clean this is
>     now.  For the setting up and processing of the plugin, I now use a
>     function-closure to hide variables instead of attaching them as
>     public statics on the plugin.
>     The working example is here:
>     http://www.flensed.com/code/dev-tests/test-dojo-xhr.html
>     The plugin code is now here:
>     http://www.flensed.com/build/thirdparty/dojo-20080828/dojox/io/flXHRproxy.js
>     What I've taken the step of doing is essentially putting only one
>     item into the dojox.io namespace, "flXHRproxy", which is actually
>     itself a reference to the global "flensed.flXHR" namespace.  Then,
>     I add the "registerOptions" function onto that same reference
>     (essentially dynamically extending flXHR instead of dojox.io
>     directly).
>     As you can see from the HTML, this has the simplifying effect that
>     to register one or more URLs with flXHR, you call each time:
>     dojox.io.flXHRproxy.registerOptions("http://.....", {...});
>     Also, there's no more need to do the "adaptDojo()" mess that I was
>     doing in the first attempt at this plugin.
>     Moreover, for dojo users, to reference any of flXHR directly (like
>     to use its static constants for error codes, for instance), they
>     now would just do it like this (since "dojox.io.flXHRproxy" is now
>     a static reference to flensed.flXHR):
>     dojox.io.flXHRproxy.#whatever#
>     With this reorganization of namespace stuff, the only effect now
>     is that a user of this plugin would have a "dojox" and a "flensed"
>     in their global namespace, but all code they would write reference
>     only the "dojox" namespace, and the "flensed" namespace would just
>     simply be ignored (or unaware to them) and sit there quietly
>     (necessary only for flXHR's own internal processes).  So yes, it's
>     two namespaces, instead of one, but it's pretty clean
>     comparatively and it keeps dojox and flensed playing nicely together.
>     What do you think?
>     --Kyle
>     --------------------------------------------------
>     From: "Kris Zyp" <kris at sitepen.com>
>     Sent: Wednesday, October 08, 2008 10:29 PM
>     To: "Getify Solutions, Inc." <getify at gmail.com>
>     Subject: Re: Dojo Cross-site plugin for flXHR... WORKING now  :)
>>     Hash: SHA1
>>     Getify Solutions, Inc. wrote:
>>>     all flensed projects (including flXHR) are released with MIT
>>>     license.
>>     That's good.
>>>     I guess what I was hoping was that the flXHR plugin module (just
>>>     the plugin code itself) could be part of the DojoX release, but
>>>     still just either a re-distribution of, or at least a direct
>>>     linking to, the regular flXHR distribution (which btw is all under
>>>     one global namespace as well, "flensed"). I think it'd be pretty
>>>     onerous to try and change all of flensed to work under the Dojo
>>>     namespace itself... I don't know, what do you think is the best
>>>     way? Certainly, regardless, I'll be publicly linking to and
>>>     publicizing the new Dojo plugin, whether I host the code, or
>>>     whether it's part of Dojo proper. I just felt like it might lend a
>>>     little more credibility to the plugin if it was something part of
>>>     DojoX itself.
>>     I suppose another option is that I could include the plugin in
>>     DojoX,
>>     without the flensed/flXHR core. That might give it more visibility,
>>     and I would just include in the documentation that the user needs to
>>     download flXHR. I don't know if that would be good or if it would be
>>     frustrating to find that the module doesn't work unless you download
>>     something else. In general, the Dojo library is pretty strict about
>>     avoiding addition of global variables/namespaces outside of it's
>>     own,
>>     but I can talk to some others and see what they would suggest.
>>     Kris
>>     -----BEGIN PGP SIGNATURE-----
>>     Version: GnuPG v1.4.9 (MingW32)
>>     Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>>     iEYEARECAAYFAkjteqwACgkQ9VpNnHc4zAyRvgCfecK8dTKnKKrTPTAhbLipeN9B
>>     Un4An0iMmzEyi7MXtHW2Omnb6pjPQXGG
>>     =qu2b
>>     -----END PGP SIGNATURE-----

More information about the dojo-contributors mailing list