Marc's Voice

Reciprocation, Open APIs and caching data coming from web services

Stewart Butterfield must be proud of himself!  He deserves a good nights rest after this on-slaught - attacking his integrity, best intentions and strategy.  Brad Horowitz must be proud of him - as well.

Reading over the comments (I posted the #112 one) on Michael Arrington’s original, slanderous post - it seems to me that Stewart’s so-called ‘change of heart’ is exactly the right answer. 

Reciprocation.

Of course  Its somethiing I completely assumed, but was pointed out to me (thanks Tara and Chris) was not necessarily being granted by Zoomr.  Many debated this issue and I think we’ll go over it at Bloggercon IV - as well.

So lets be clear.

Open APIs are a two-way street and Stewart and Flickr have set a precedent - as they’ve done so many times before - on demanding that any commercial vendor who wants a commercial key, MUST also provide clean, clear, open APIs - going in BOTH directions - from their system.

That seems not only fair but smart.

Now regarding WHERE a user’s data is stored, this is the old ‘data storage in the clouds debate’ - rehashed.  Antonio Rodrieguez points out that it’s completely reasonable to leave an end-user’s photos in Flickr, [via Doc] while accompalishing the tasks (in Tabblo’s case - hard copy printing) - at hand.

But let me point out a simple thing. 

Its really hard to create a compelling end-user experience when you’re linking to external sources.  We’ve been trying it for over a year now - with some sucess, but in general if you want to include (let’s say) your external blog in some other service - its far from satisfactory experience.

DLAs (digital lifestyle aggregators) like the PeopleAggregator can easily handle data being stored - wherever.  We’ll eventually even have a formal VFS (virtual file system) to keep track of where the hell all your stuff is.

But all data stored from some remote web service needs to be cached - as no end-user is gonna be happy waiting for their pages to update - while pulling in data from that remote web service.  This is a crucial UI issue.

So as the dashboard category grows (Pageflakes, NetVibes, Superglu, etc.) expect to see further and further sophisticated caching of data coming from web services - just to make these dashboards usable.

Now where does that put us in the Open APIs debate?

Right smack dab in the middle of it.

Cause once we have Open APIs moving in both directions, and we’ve given our end-users the ability to move their stuff around - we ALSO need to give them the ability to cache this data - so they’re not waiting for their remotely linked pages - to update.

This is where Tucows comes in.

They have launched a ‘Feedcache’ service - which I believe can be expanded to become a personalized ‘web services’ cache service - for ALL to use. I had a great conversation with Ross Rader about this - a couple of months back - and like all good ideas- this idea’s day has come.

 BTW I have pitched Antonio’s service to several of our cleints and they all say “sign me up!” So congrats to Antonio!