[dojo-contributors] Flash Cross-Site Access Plugin

Mike Wilcox mwilcox at sitepen.com
Thu Oct 9 12:44:42 EDT 2008

It certainly is an impressive plugin.

The externally library will present problems. There was some conflict  
when the new Firebug Lite was introduced with it's own library.

Also, I wonder if it duplicates code already in DojoX, specifically  
the dojox.embed.Flash.

Finally, the primary reason for the Deft project was to be able to  
include SWFs as resources; and that SWF code would be publicly  
available, viewable, and modifiable.

For it to be eligible for the Deft project, it would need to be  
compilable with the Flex SDK mxmlc. An FLA will not work (not open  


On Oct 9, 2008, at 11:25 AM, Kris Zyp wrote:

> 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
> dojox.io.xhrPlugins.
> 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):
> http://www.flensed.com/code/dev-tests/test-dojo-xhr.html
>    Oops, that link should be:
>    http://www.flensed.com/code/build/thirdparty/dojo-20080828/dojox/io/flXHRproxy.js
>    --Kyle
>    --------------------------------------------------
>    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-----
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://turtle.dojotoolkit.org/mailman/listinfo/dojo-contributors

Mike Wilcox
mwilcox at sitepen.com
work: 650.968.8787 x218
cell:	  214.697.4872

More information about the dojo-contributors mailing list