slayeroffice

• Four Corners
• HTML5, the
• An Introduction to HTML5
• Mouse Patterns: Canvas Version
• Devnation Slides
• The Challenge of Easy Integration
• aimapi-core and SocialThing
• Does it .match?
• Emre Grayson Chipman
• SXSW Time!

aimapi-core and SocialThing

Oh hi, long time no speak. How's every little thing?

I've spent the past few months working on the SocialThing for Websites client, which you can see in action on AOL's country music blog The Boot. Techcrunch didn't tear it apart, and the comments aren't as rabid as one might expect on an article about an AOL product, so I suppose it came out next-to-all-right.

The client itself was a lot of fun to work on, and there were a lot of interesting technical hurdles that we had to hitch our pants way up and leap over which kept things awfully interesting. More on those later, though.

For now, I wanted to point you towards the backbone of the SocialThing client, aimapi-core.js, now hosted on Google Code. This is a pared down, bare bones, just-what-you-need-and-nothing-else version of the original Web AIM Javascript API that AOL released back in November of 2006.

So, you ask - besides dropping all the UI stuff that you weren't particularly interested in the first release, what's so great about aimapi-core? Well...

• Its only 44k (with white space and comments). The original is 80k and does less.
• More transactions (some of which didn't exist in 2006):
  • addBuddy and removeBuddy
  • getStatus and setStatus
  • getBuddyFeed (AIM's lifestream - see buddyupdates.aim.com)
  • pushFeed - a means of pushing content into a user's buddyfeed/lifestream
  • reportSpim
  • and more!

• Alternate means of listening for events. The original codebase used long polling via script nodes. Unfortunately this meant rapid polling in Firefox because of a bug in that browser that prevents more than one script from downloading at once. This rapid polling was both memory intensive and had the status bar constantly letting you know that it was "Waiting for 12.345.79.80..." which kinda sucked.

  So how was this resolved?

  • If AIM.params.useSWFListener is true, the API uses swfobject to pull in swfsocket.swf which uses AS3's socket API to listen for host events (IMs, presence updates, etc). Many thanks to my pal Rick Gardner for writing this piece.
  • If swfsocket fails to initialize, the API falls back to scriptiframe.js, a clever work around that James Burke came up with that uses an iframe to long poll for events.

  And if all that fails, it goes back to using dynamic script nodes to listen for host events.

• And more! (...that I still need to write documentation for!)

So give it a look, and let me know what you think. Oh, and for those wondering - no, the SocialThing client is not a frame a' la the diggbar. Come on, give me a little credit.