An API for providing access to data to 3rd parties would need to provide the following variations:

1. Raw data - XML/Yaml/JSON; useful by 3rd party servers that can retrieve data from 3rd party sites - your site - and manipulate and send it to their clients
2. Javascript callback; called within XSS context only - - your returned javascript invokes a callback function on the 3rd party site. Best to allow the option of the 3rd party specifying the name of the callback, though this makes caching harder.
3. Variable setting; user as per #2, but the returned javascript sets a known variable with the returned JSON value. Why? So that you can now access within your own inline javascript. E.g. if the variable VERSION is upated with a version value, then a 3rd party might use the following: <script src=”http://yoursite.com/getdata”></script> <script>alert(”Current version: ” + VERSION);</script>

I think I first saw this triplicate of XSS API options on http://cocomment.com but I can’t find it on their site now.

These three API versions should be supported by the same controller action - they access the same server data - and the required value might be selected by a params setting: context = raw/callback/variable.

The idea of 3rd parties pinging for the version number is also very cool - just like a feed reader polls for new articles on an RSS feed every 15 mins or so. Especially if projects adopted a convention - e.g. all have a version.xml file with the same schema.

This being the case, it would make more sense for version.js to be replaced or partners with a version.xml file or version.yaml.

I still like the inherent fun of embedding data within a snippet of loadable code. The data only coming to life when the javascript is executed If the version.js was instead an RJS call to your rails app, then instead of executing document.write(VERSION), you might want the RJS code to execute a local update function:

page.version_manager :update, @new_version

which would execute the following JS at the client:

VersionManager.update('0.8.1')

And you’d just need to provide the VersionManager.update callback function in a library.

If it were your server and 3rd parties wanted to call your RJS action, but they wanted to be able to specify their own callback action in the params, then you are now being super sexy. The 3rd party can easily use your RJS action for XSS without having to do any processing of data. They just insert and the resulting JS will invoke their VersionManager.update callback function with the result.

Remember, you can’t use Ajax to request data from a 3rd party site, so XSS is sometimes all you’ve got. AdSense uses it - probably the most pervasive use of XSS in the world. No callbacks, no interaction - you just trust google will execute nice JS on your site.

So, even if the solution includes providing a version.xml file, 3rd parties may want a configurable callback action option anyway, just because that’s all they can use on their own site.

Now we’re getting complex - we’re providing 2+ ways to get the data (xml and callback invocation). That’s ok if you’re generating the two files (the callback method would be hardcoded here). But really, what we’d like is for RubyForge to generate these values for us from their own data. Then we wouldn’t need to write an explicit version.js/xml file at all!!

Sniff. I smell a good idea here. First person to write a public wrapper for RubyForge’s Release values per project file, that provides 3rd parties with raw XML and YAML release version strings, and a configurable callback method action, gets extra Christmas presents.

It makes too much sense for someone who wants to release a micro-public utility site themselves NOT to do.

You also get an extra Xmas present if you convince Ruby Central to provide a nice API into their RubyForge database.

1. The Magic Edition - Awesome. I love pages that inform me of changes since I last visited.

2. Creating a convention for retrieving the Version of your Products/Projects makes it easier for you AND me to query for it. I can now programmatically compare my local version against the published version. Thanks.

3. IMHO, I would like to keep the formatting in the sidebar – not my projects. It’s the view’s responsibility and… I don’t want to parse out the format du jour when I grab your version.
Solution: That just requires a quick tweak to your method (move “-” to sidebar, remove from version.js). If you want to DRY up the sidebar formatting, you could make a local script.

4. IMHO, whether you call it Cross-Site Scripting or not, it seems wrong to run a script from another server just to retrieve a version number. I hope this feeling isn’t coming from my “Web 1.0” comfort-zone.

Possible solution: How about creating a page in our project that just returns the version number (html, xml, json)? We could then populate the sidebar values during Server-side rendering or using Ajax.

4a. Retrieve versus Populate: This also makes it easier to create a Project Version page that programmatically retrieves the current version when the page is requested. A Rails View would work nicely for this - even handling many content types so you could request the Version in whatever format you want. I would much rather request the version (cached where necessary) than be forced to ensure the version.js file was updated every release. An Automated build will just automate the step, not eliminate it. Besides, I know how to Test the Page.

4b. Or… this could all be unnecessary complexity. I have been known to indulge in that area from time to time. I acknowledge that it happens, but haven’t quite grown the skills to recognize it each time. Reviewing 4a makes me wonder if I also have the dreaded “buildophobia” (cured only by adequate test coverage).

Retrieved or populated, I see merit in some variation of the Version Page becoming a convention. Can a RoR plugin be far off?
–Thanks again, Matt