06 July 2010

A Plea to Providers of Open Webservices

Let's suppose you have a webservice, and you have decided, out of the goodness of your heart, to make it "open". Anyone can browse it, search it, and utilize the data it provides. This is something you wantfor anyone to be able to utilize the data and present it in new, creative ways.


I'm willing to bet you missed a step.


Consider my Flash application, Names on Nodes. Right now it's a standalone program—it can import and export files locally from your system. But it doesn't read data from any webservice. There are many places in the program where it would be extremely useful to do so. For example, instead of having to enter LSIDs manually, it could search for them in uBio. Instead of having to open NexML files locally, it could pull them from TreeBase. Wouldn't that be nice? Why haven't I done that?


Well, fact is, I can't.


The Flash Player has a security mechanism whereby it will not load data across different domains. If my SWF resides on namesonnodes.org, then that is the only place it can load data from. Of course, there are ways around this: a good way, a less good way, and a really stupid way.




The Good Way


If your domain has a file called crossdomain.xml in its root, then the Flash Player will read that to see if cross-domain permission has been allowed. Here's an example of a crossdomain.xml file that allows maximum access across all domains:


<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.adobe.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
   <site-control permitted-cross-domain-policies="all"/>
   <allow-access-from domain="*" secure="false"/>
   <allow-http-request-headers-from domain="*" headers="*" secure="false"/>
</cross-domain-policy>


(Or, download it here.)


For more information, see the Cross-Domain Policy File Specification.


(Note that the folks at TreeBase are looking into this. I'm on tenterhooks.)




The Less Good Way


I could also make Names on Nodes as an AIR application. This is less good because it means the user would have to install it as an application on their local system, and they couldn't just access it online. But it would allow for more possibilities—not just the ability to load data from anywhere regardless of policy files, but also drag-and-drop from other applications, etc. I am actually planning to create an AIR version someday, but it's not my top priority right now.




The Really Stupid Way


Of course, I could also make a little server-side component on my domain and simply have it pull data from your domain before feeding it to the Flash application. This is really stupid because it greatly increases traffic on my webserver while still causing just as much traffic on your webserver as it would if you had just allowed cross-domain access with a policy file.




In Summary


It takes a matter of seconds to place a cross-domain policy file in your server's root directory (assuming you have access), there are no drawbacks if your service is intended to be open anyway, and there are huge benefits for us Flash developers who want to use your service. I mean, really, why not?

6 comments:

  1. Hmm...having traded in my tired BlackBerry Storm for a Droid X, and seeing Adobe's announcements today regarding Air on mobile platforms (http://www.droid-life.com/2010/08/16/adobe-android-summit-is-go/#disqus_thread) I have to say that I am becoming partial to solution 2 (your "less-good" way). Names on Nodes on my smartphone would be freaking awesome for conferences, coincidental meetings with collegues...or well, anytime I want to talk phylogenetics with someone and we aren't in my office.

    ReplyDelete
  2. Duly noted--I'll look into that later this year.

    ReplyDelete
  3. This is a kludge to allow webservices to be consumed by broken/poorly architected tools like Flash, not a "missed step" as you indicate.

    While I don't disagree with using the XML file, I do disagree with your Flash-centric description of the problem. Wouldn't a better description be to "make Flash more open like the webservices it consumes" instead of "you forgot to make my use of proprietary tool X easier to use"?

    Just a word of caution when you attempt to comment on things outside your primary domain of knowledge ;)

    ReplyDelete
  4. Don't throw a hissy fit, just put the stupid file up! ;P

    ReplyDelete
  5. And other client-side tools (e.g., AJAX) have the same problem or worse, anyway.

    ReplyDelete
  6. And if you have a better idea for how the Flash player should determine whether a server is intended to be openly consumable or not, tell Adobe.

    ReplyDelete