Problematic Twitter API Cap

21 January, 2009

Though unfortunate, if tuned and re-architected a bit,  I don't believe the 20,000 calls per hour cap would shutter many Twitter dependent services. That is, if they don't try to continue to operate as they have. I believe the future might be a return to the concept of timeslices from the dark ages of computer science. More apps should run on the desktop. Forget supported by ads, it should additionally be supported by processed work units. For the average user, I think even netbooks have enough headroom to not be affected. I admit that each situation is unique and this isn't a panacea and is more of a braindump.

One of the benefits of the a desktop app and Java applets in particular, though the latter has be vilified by the faux pas of amateur Swing developers, is the fact that that they usually run in a sandboxed VM on the user's machine. This is a feature I took advantage of when creating FriendBackup. Because it ran on the user's machine so I never had access to their data and because they were communicating directly with the Twitter API, I didn't incur a cap. I know that the browser is the lowest common denominator but who says the meat of the application has to run only your servers. I'm not saying you should use Joe Schmo's machine to parse the data from @Scobleizer but you could easily wire up your own pseudo-SETI@HOME with some Hadoop/MapReduce magic to have the users process a couple packets of information and send it back. It's not optimal but it should work.

Though I've not tried them (but have signed up for their beta), Plura Processing allows developers to earmark CPU time to process work units. They currently support Java applications and websites. It would be a pain to engineer but it would provide some headroom to work with the caps. As long as it's unobstructive, clearly stated in your ToS, I don't think users would mind a couple packets here or there.

Why does everything have to run in the browser? We can use AIR, Griffon, Silverlight, a draggable Java6 applet, whatever. It is starting to box us in. The decision of Google devs to make the Native Client is becoming more clear.
 

Share/Save/Bookmark

Comments

Leave a comment