Life & Research Notes

Lately a few of my social circles seem to be hitting a critical Twitter point, with more people on talking about what they ate for lunch or having weird little conversations or whatever. I’m using it over IM, and it’s fun, definitely distracting, and I think I finally get the hype a little more. It probably won’t be the crazily addictive service for me that I’ve heard it is for others, especially since I refuse to turn it on for my phone. Still, the combination of immediacy with publicness makes it very intriguing.

It’s also not hard to imagine scoping Twitter to selected teams and companies, so the communication is open and archived only within that context. Perhaps this is in Twitter’s business plan, or in someone else’s.

More than anything, whenever I use Twitter I often recall a meme I picked up from Burak’s delicious a while back, that XMPP (Jabber) may be the future of internet services. It’s actually a very simple premise: compared to HTTP polling, XMPP is much better suited to 2-way, stateful, immediate communication. The post comes from an interesting company, Jive Software, that focuses on collaborative systems for business. They clearly have been thinking about XMPP a lot.

Consider a hypothetical platform for public and private data to flow in continually as time-series streams. In almost all cases, the way new data is collected and pushed to this service would be by polling the original source to retrieve the latest update, maybe massaging the data into the right format, then POSTing/PUTting to our service. But rather than this automatic checking and reposting, what we really want is for the data source to just tell us when there is new data, and to either push it to us, or give us a url to retrieve it at. We’d like to register with that source, and from then on continually receive updates as they happen.

Or, since we’re working with data over time, perhaps we’d like our service to nudge data stream providers for the latest data when it’s time to provide it. “OK, it’s been an hour, give me your latest.” If the data script doesn’t provide anything, then we can stick null values in there and just say there is a gap in the data stream.

XMPP makes it easy for either side to initiate the request, and for exchanges to happen as soon as they need to. It’s also been proven to scale well, and there are a ton of clients and libraries out there already. It’s definitely going to play an increasingly important role in services talking to other services, and I’m fairly certain it is the right way to approach data streams. But until then, I’ll just be twittering.

respond / trackback