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 want—for 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?