I had analyzed opensocial applications in the past, but writing an application is a whole new thing. I found some free time this weekend and finally decided to put the months of lazy reading to work. The API was good, but I did have some issues with caching. I don't have a external server and prefer development on my localhost using Apache Tomcat.
However, google demands that the files need to be externally visible, something that makes my build process longer. Hence, I thought that simply hosting the gadget application xml file externally, with source locations pointing to localhost should work. Interestingly, the Opensocial engine parses the application xml and modifies the source even for the script and image tags present in the file.
The technical explanation for this seems to be that this is done for caching and is the default behaviour. Such a substitution also happens for HTML/Text content fetched over gadgets.io.makeRequest. This is a main reason why development on localhost can't be done.
The caching advantage this idea provides is definately good, but I am not a great fan of making this the default development mechanism. Some of the disadvantage are
- Develpoment requires externally visible server
- Referrers are from google; depending on referrers for anti-phishing / anti-replay may not work
- Flash will not be served from the same domain, so script access may have problems
- User location may not be tracked
- Application that have images or scripts that update in realtime will still be served through google.
As a result, in the application that I am currently writing, my app.xml simply appends a script tag to the body. This script then loads my HTML file, directly from my server. Note that this HTML is already converted (using this) to a JSON string by a filter (or a tag library) at the server. This is picked using YUI GET. This also keeps HTML content separate from the Javascript files.