Yahoo! – components that matter to me after no search

YGMThe news of the week (month/year?) is the $44.6 billion offer from Microsoft to acquire Yahoo!. Robert Scoble blogs the intelligence of Google’s email and Dave Winer drops thoughts on Yahoo’s options based on TechCrunch blogger Mike Arrington’s analysis. Mike Arrington’s latest news is a bit disheartening. Either sell to Microsoft or sell their search to Google.

Yahoo! has a lot more than search to offer – it shouldn’t be their primary business. As Scoble and Winer both pointed out, the wars are being fought on platforms – Especially the mobile platform. Yahoo!’s Go service synchronizes calendars, contacts, etc, from phone or PC and runs on Windows, OS X, BlackBerry, Symbian (Nokia), and Windows Mobile. Heck, it runs on almost every phone out there and OS X has Yahoo Sync built in. It’s been over a year since I’ve synchronized my phone by wire and I’m able to keep three phones and two laptops in sync.

Dave Winer shares insight from past technology wars while asking which platform will be adopted as the standard for synchronization of contacts, social networking, etc. I argue it could be Yahoo!. They’re embracing OpenID and offering Pipes. The Go service has plugins which tie in to MySpace and other social networking sites. They’ve got an identity system, a delivery method, and a decent reach in to the mobile market.

Finally, Yahoo’s two destinations – Yahoo! Music and Yahoo! Finance. These two are both number 1 in their class. Numero Uno. Why? They have content. Google offers search – when you’re looking for content. Yahoo!’s Music and Finance (and other sites) have that content.

These are the Yahoo! products that matter to me and the reason I’m a Yahoo! shareholder. If the sale goes through I’ll happily cash out with a profit and start looking elsewhere for services that satisfy consumer need.

The dream mobile blogging device is dead

O2 XDA ExecMy favorite mobile blogging device is now listed on eBay. The HTC Universal has a usable keyboard, beautiful touch screen, plenty of horsepower, 3G, Wi-Fi, BlueTooth, dual-cameras etc.

It met its demise in the outer pocket of a WWDC07 laptop bag (yes, my bag, d’oh!)… Cracking the screen and becoming unusable. I don’t feel like doing a screen replacement. It’s now up for sale and I’m using the iPhone as the primary, with the BlackBerry 8800 as a backup. I’m hoping HTC will make another similar all-in-one device for mobile blogging soon – preferably with Windows Mobile 7.

Harnessing a web service API with JavaScript – use the three-peat to avoid DNS failures

iofy download serviceWe’ve recently done work harnessing our iofy RESTful web services in JavaScript, especially the account management sections. Typically, in old-school fashion, an account management system is done server side with PHP, PERL, Ruby, etc, interacting with a database.

<sarcasm>That’s great when you want your heavy hitting developers to do design work or when you want your designers to do low-level work (or if you want to add a layer of management to your project where you need to separate out what parts of a page are owned by what developer/designer.)</sarcasm>

Why give yourself that headache? I had that headache for a while and have a direct solution. REST + JavaScript. My heavy hitters delivered RESTful functionality for our API that can be harnessed by pretty much anything capable of HTTP. My webmaster and designers can now, purely in JavaScript, harness this API and deliver all the functionality they need with all the gorgeous style they possess.

You can too (drop us a note and sign up as a reseller.) Our API is REST and we’ve got JavaScript libraries for harnessing it. The JavaScript queries the web service and receives an RSS 2.0 response. Parse it, and you’ve got everything you need for account management, content delivery, sales, and reporting.

Now for the difficulty in JavaScript web service API harnessing… The big surprise we ran in to initially was with the failure rate of HTTP requests from client-side JavaScript calls. DNS stinks. We would make requests and randomly get failures. As it turns out, DNS will fail between 1% and 3% of the time on a typical DSL connection. You need to retry that connection…

I recommend the three-peat for failed connections. In your JavaScript (or any other language), use asynchronous calls to a function which will repeat the HTTP request up to three times before erroring out. This reduces the likelihood of failure to a cube of the failure rate.

The worst DNS providers fail 3% of the time. Therefore the first request has a 3% chance of failure. The second has 0.09% chance since the 3% that failed are 3% likely to fail again (3% multiplied by another 3%.) The third try won’t fail unless something bigger is going wrong, drops the chance to 0.0027%. This is far more acceptable than 3 in 100 and effectively removes the DNS issue of web service connections.

XMPP stands for scalability

XMPPCart 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.

M1 AbramsMonstrous 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.

Performance is everything

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.

iofy download iconNow 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.