Comments on: Twitter over IP

By: Gavin Carothers

Gavin Carothers — Wed, 04 Jun 2008 10:43:00 +0000

I think that XMPP is very good solution for the “Twitter” system, there’s already been a good deal of work on the pubsub extensions which would allow for the more persistent twitter like service. See: http://www.xmpp.org/extensions/xep-0060.html

By: marxy

marxy — Wed, 04 Jun 2008 10:43:00 +0000

Certainly users are much more likely to be able to get through using HTTP, but Skype appears to have worked around this issue, at least for one to one or small groups.

I wonder why they didn't just adopt XMPP?

By: Chris

Chris — Wed, 04 Jun 2008 10:43:00 +0000

And so long as we're quoting XMPP standards... take that!

(This post is an obvious departure from my usual style of blatant attack pieces in order to score traffic and fame for myself. Normal service will resume shortly.)

I think you're hatin' on XMPP by not mentioning it in your post.

By: Andrew

Andrew — Wed, 04 Jun 2008 10:43:00 +0000

Can you elaborate on why they didn’t have much choice about using HTTP? Why was something like, say, BEEP, not an option?

By: Asbjørn Ulsberg

Asbjørn Ulsberg — Wed, 04 Jun 2008 10:43:00 +0000

Seeing how Twitter’s integrated with XMPP already, I’m really surprised that they aren’t offering a full-fledged API over XMPP, 100% compatible and feature-equivalent with the HTTP version. When this option exists, it’s all up to the Twitter clients (like Twhirl, Twitterrific, etc) to support the new API instead of the HTTP one. Over time, this will reduce the load on the HTTP API and thus on Twitter’s servers alltogether.

By: Sunny Kalsi

Sunny Kalsi — Wed, 04 Jun 2008 10:43:00 +0000

In the olden days of internet, there were many protocols -- ftp, ICQ, IRC, etc. and a lot of them were not HTTP. Then eventually the people who maintained the firewalls at workplaces started blocking all the ports and a lot of people got annoyed when their software didn't work with NATs.

The only way to get around both firewalls and NATs was by using HTTP. The issue with both firewalls and NATs is somewhat similar. With HTTP traffic it's easy to determine that the traffic was requested, and who in your network requested this traffic.

It makes me so sad when I think about all those routers and machines out there which no longer reply to a simple PING... I remember when computers used to talk to their neighbours, tell them what was up, their TTL to their destinations, like good god-fearing components. Computer society is turning into real society.

By: Alastair

Alastair — Wed, 04 Jun 2008 10:43:00 +0000

Thanks all for the XMPP lovin'. Wikipedia points to some possible scalability concerns with XMPP and large numbers of participants, not sure if they are still valid.

But even if XMPP does solve some of these problems, I think there is still scope to look at different network layer protocols. I mentioned UDP multicast, but is anyone else interested in SCTP? I think it's very promising, or at least would be if end-to-end was practical.

Chris: The very existence of the BOSH technique kindof proves my point. Sure, it's possible to come up with workarounds at the application layer for network layer limitations. But these can have unintended consequences.

Andrew: I think Sunny has sort of answered your question, although it's not accurate to say that HTTP was invented as a firewall bypass protocol. Still, it certainly is the lowest common denominator these days, and if you have a new application it's highly preferable if it can be sledgehammered into a client-server model and crammed into HTTP. If you don't, your users may end up dealing with firewalls, port forwarding, and all that nonsense. Sub-optimal either way.

I've just thought of a new, catchier title for this post: HTTP is the new TCP.

By: Adult Ühler

Adult Ühler — Wed, 04 Jun 2008 10:43:00 +0000

I’m also wondering why not just use XMPP?