Sol Young

Cart sent me a link to Matt Tucker‘s latest blog entry over at Jive Software, “XMPP (a.k.a. Jabber) is the future for cloud services.” Matt is right. Cloud architectures and large systems are moving away from the current HTTP / web services integration.

Monstrous servers and clusters banging on each other, effectively pulling web pages in order to deliver another web page elsewhere, is like having M1 Abrams tanks outfitted with BB guns instead of cannons.

At iofy we’re using web services with HTTP. We don’t like SOAP, but we’re RESTfully clean. Our web services API is unintentionally somewhat like Twitter’s API. However, there is a key difference. We use callbacks.

Callbacks allow partners to integrate with iofy’s web services without having to poll for updates. Both Yahoo! and Flickr do this for integrating customers.

We’re similar to Yahoo! in that the stores we power, such as The Language Stop, do not require persistent connections and would be inconvenienced by needing to implement anything larger than web service integration.

In order to keep things simple and fast (and not destroy your architecture with a polling only API) offer callbacks on top of polling. Any mid to large partner, or technically savvy smaller partner, will prefer the callbacks.

The recent debates about Twitter’s performance has me thinking about iofy this weekend…

Way back when I started at iofy we had the challenge of creating PC and PocketPC applications that played secure audiobook content, displayed table of contents meta data and bookmarked. The applications needed to be under 200k, run on a 200MHz processor and be stable.A latent requirement was that the applications, to satisfy our reliability requirements, had to be statically linked so they could run from a chip without handling varying customer system configurations. Statically linked Microsoft libraries and our code within 200k in a real application. What?

Optimize, optimize, optimize.

Now we’re launching our download service which takes our original offering from a single chip on a single computer (or player) to a service which offers downloadable audiobook content.

There are more performance areas to optimize than you can shake a stick at (client, servers, db access, feed syncing, backups, etc). We’ve stuck to standards and performance as principle design requirements (and we’ve swung intelligently with big sticks.)

As we roll out iofy’s download technology I’ll touch on standards we’ve stuck to and how they may apply to you. I’ll be touching on performance considerations we’ve addressed, especially with feed synchronization. There will be pointers on how you can best integrate your eCommerce system with iofy’s API to offer downloadable content.

This is an exciting time for our engineering team at iofy. We’re seeing our latest hard work make its way to the mainstream.