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!

6 Responses to “Reciprocation, Open APIs and caching data coming from web services”

  1. Marshall Kirkpatrick Says:

    Dude, Arrington didn’t write that original post, I did. And it wasn’t slanderous, it just didn’t include enough and up to date details from one side of the story. Isn’t calling something slanderous that isn’t slanderous a form of slander? Lol. Anyway, the issues that need to be discussed are getting discussed.

  2. Venture Chronicles Says:

    [...] This is exactly where the notion of mashups comes up a little short in my opinion. It’s exceptionally difficult to deliver a service that features dependencies on 3rd party services, both from the user experience standpoint but also from performance and reliability. Mashups are a stepping stone to something more meaningful that has yet to be defined. Marc’s Voice » Blog Archive » Reciprocation, Open APIs and caching data coming from web services: 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. Technorati Tags: mashups Posted in Innovation || [...]

  3. devlon duthie » Blog Archive » links for 2006-06-21 Says:

    [...] Marc’s Voice » Blog Archive » Reciprocation, Open APIs and caching data coming from web services 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 (tags: API webservices) [...]

  4. that would explain Bob… » Blog Archive » API and Fluff Says:

    [...] And outrage and concern over users API is being soundly argued clearly here, here and here oh here and here and woops not here (that is the launching of the new product, I get Fluff and Marc confused so often ! [...]

  5. Bradley Horowitz Says:

    Yep, I am proud of Stewart. As much as his decision, I’m proud of his willingness to engage, discuss, and ultimately be “wrong” and have a change of heart. What a guy.

  6. Bradley Horowitz Says:

    Oh, and I had nothing to do with it. Been in Singapore, largely offline. Missed your open letter. Call me next time!