Blogs

There was a recent post on Ajaxian [1] about a “call to arms” by Sam Schillace from Writely [2] for open mash-up APIs. Essentially the jist of it was that people who are developing Web 2.0 applications should create APIs in some “standard” format to promote interoperability between services. From what I recall there has been a lot of effort put towards describing interfaces to web based services using some sort of standard XML based vocabulary. So just because it is Web 2.0 does that mean we should simply ignore everything that has been done in the past and try to re-invent the wheel Web 2.0 Style at every chance we get? Anyhow, Chris Kolhardt of Silver Tie then offered up some more ideas about this [3] regarding what needs to happen for an open API. I have listed the ideas below and I offer my comments in devil’s advocate style …

Single sign on and Identity management, using an open standard … This would be great in a perfect world. There are many problems with SSO not the least of which being users not trusting who owns your identity information (do you think that Microsoft was using Passport just to make your life easier …) or the risks of forged credentials (sure just because the user has an eBay account doesn’t mean much). EWallets and the like were all the rage during Web 1.0 and not even Microsoft could make Passport work - we might be waiting a while for this despite the hard work of our fellow Vancouverite Dick Hardt over at Sxip.

Ability to list and select resources from other services … there have been lots of engineers working on this problem for some time and just two examples of the results being UDDI and ebXML Registry which are both already “standards”. I can’t help but ask why do we need more “standards” like this? Oh sure people may find it to be too complicated but the the problem itself is actually quite complicated. Here is a novel idea, why not use the existing standard for descibine web based service interfaces called WSDL. What? Use a standard from W3C? That is sooooo Web 1.0, we want ad-hoc micro-formats and useless folksonomies.

Ability to easily import documents from one service, and embed them in another, even if the imported document is not publicly published to the world … this could be really difficult. Of the four problems mentioned this one actually sounds somewhat interesting.

All the while keeping in mind that the user experience must be easy and seamless … sure we can do this thanks to the AJaX technology of Internet Explorer 5 circa 1999.

These sort of ideas just re-affirm my belief that Web 2.0 is actually is more hype than version 1.0. It seems that the combination of tech buy-outs (Flickr, Blogger, Upcoming, whatever) by successful Web 1.0 and previous companies (Google, Yahoo, Microsoft, etc) and the fame achived by people who make simple Google Maps mash-ups is causing a lot of entrepreneurs to see bags of money again. While Google has a real business plan that makes them money the new Web 2.0 business plan, unlike the Web 1.0 busines plan of trying to actually make money (this is _obviously_ where Web 1.0 went wrong), can be summarized in four easy steps:

• provide free social software (bonus for using tags or AJaX)
• get as many people to sign up as possible
• sell to Google/Yahoo
• profit (of course)

references
[1] Open Mashup APIs - Ajaxian, Oct 17, 2005
[2] Mashups and Openess - Sam Schillace, Oct 7, 2005
[3] Standard Interoperability API - Chris Kolhardt, Oct 8, 2005

For those of you who went to VanX (or didn’t and want to see the gory details) then here is my presentation in evil MS PowerPoint format

Alternatively you can view it in the just as unfriendly PDF format here.

I should also direct people to recent articles written by EBA people that have been keeping us busy … not mention all the work
Is AJaX Here to Stay? - Jordan Frank
AJaX: Dawn of a New Developer - Dave Johnson
Measuring the Benefits of AJaX - Alexei White

Just a quick post about running AJaX offline. With the recent release of Flash 8 it seems a good time to bring this up since Flash 8 has everything you need for a robust cross-browser data persistence layer. The two main features of Flash 8 are the SharedObject (although this has been around for a few years now - since Flash 6) and more importantly full JavaScript support. The SharedObject allows you to store as much data as the end user wants to allow and this limit can be configured by the end user.

In the Flash file you can use the ExternalInterface to expose methods to the JavaScript runtime like this:

import flash.external.ExternalInterface;
ExternalInterface.addCallback("JavaScriptInterfaceName", null, FlashMethod);

Similarly you can call JavaScript functions from within the Flash file using the call method of the ExternalInterface

ExternalInterface.call("JavaScriptMethod");

And you can call methods in the Flash movie from JavaScript like this:

function CallMethod() {
if (document.getElementById)
myFlash = document.getElementById("FlashMovieNodeId");
if (myFlash)
myFlash.flashFunction();
}

The other piece of the puzzle is the SharedObject which is accessible through ActionScript in Flash.

var my_SO:SharedObject = SharedObject.getLocal("MySharedObjectName");
my_SO.data.eba = dat;
var ret_val = my_SO.flush();

It is importatnt to note that if the end user specified data size limit is smaller than the requested amount of data to be saved it needs to show the Flash movie to the user (do this simply with a little JavaScript) so the user can either increase the cache size or not. The ret_val from the SharedObject flush method can be checked to see the result and determine if the Flash movie needs to be shown for input or not.

The other great thing about this is that the upgrade path to Flash 8 has been made a bit better. You can actually have the Flash 8 player installed through the old Flash player from what I understand (called Express Install I believe).

All and all a pretty slick way to persist data with AJaX without relying on cookies or the User Data behaviour in IE.