Our markets are so freaking small that making people come to us (and library toolbars, bookmarklets, jabberbots, etc. mean coming to us) is a losing battle; why don’t we better make our stuff go to them?

To try to put it in better perspective, what would you rather have in your pocket? A do-it-all Swiss Army knife? Or a toothpick (note: the Swiss Army knife has a toothpick, too)

Any time you can compose a new service out of 20 lines of user code you’re doing pretty well. ATOM and RSS can be really easy to wrap results in because of widescale deployment of code that understand how to unwrap that data. I’m led to believe that Opensearch will start to become more ordinary once IE 7 hits the streets, but again if it’s you (as a patron) writing this code you might not want to wait to bother until the library finishes their development. (Hence the ad hoc screen-scraping that goes on for amazon librarylookups…)

And I don’t think I’m contradicting myself. The “API” to request this information has nothing to do with the information (or the protocol to receive the information) itself. There are two components here. The “request method” and the response.

Where I think the value of unAPI lies is in simplifying the “request method”.

Think OpenSearch.

OpenSearch created a new “API” to “simplify” creating “dynamic RSS feeds” contextually (specifically, based on query terms). A9 (thankfully) didn’t bother to create a new protocol to enable this, they used the widely available RSS 2.0 (and, now, Atom). They did, however, create a new “interface” to RSS.

I see the same method applicable to unAPI. Create the structure around the “request” and borrow a “response”.

As I’ve already stated, implementing unAPI was easy. That’s not my argument. I just don’t want to see the very real and tangible value of unAPI wasted because the momentum of Atom is stronger or is spoken from the lips of people that have the attention of more ears.

I realize that they’re not incompatible, but, realistically, people aren’t going to implement both. All I ask is that we consider a widely deployed syndication protocol and use unAPI as a means to leverage that more effectively.

It changes nothing about unAPI except the actual response document.

But… don’t you see that to ask “why do we need another sharing protocol?” and then say “why don’t we just make a simpler API” contradicts yourself? unAPI *is* the simpler API, but instead of just speaking to one of them, it lets you speak to any of those protocols. It’s just barely enough to get the basic stuff you need out of any of them, and drops the barrier for supporting clipboard-copy out of arbitrary webapps to practically nothing.

And my point wasn’t that those other ones are too complicated for stupid
people… it’s that if it’s not *insanely* easy for anybody to implement in no time flat, nothing like this will ever take off as a standard. Anybody who knows a tiny bit of php and can read the apache docs can set up a combo of rewrites and json responses for unapi layered over wordpress, for instance. Oh, and that *nobody* cares about our wacky library jargon. The mountain ain’t movin’.

Much love, -dchud