With Twitter’s, let’s say, not so great, uptime record lately, I think it is time the Twitter API gets codified and Twitter clients start supporting different API endpoints.
For example, today you can already use fanfou.com instead of Twitter, which supports most of the Twitter API with mostly the same results, except it’s way more stable. The problem is that you can’t use your favourite Twitter clients to access fanfou, because they’re hardcoded to the API endpoint https://twitter.com/.
Then there’s Twitter proxy services that just queue tweets until Twitter is reachable again. Those, too, can only be used via their web interface and not your Twitter client.
Now, imagine this: Imagine your Twitter client allowed you to define your own Twitter API endpoint. So, by default, it would point to https://twitter.com/. But you could also write your own API proxy that would, for example, send tweets to a queue service if posting them didn’t work, that would cache your replies and direct messages so all your clients could access them without counting towards the API limit, etc.
You’d just write a handler in your favourite language and point your Twitter client at it: if I set the endpoint to http://moeffju.net/twitter-proxy/, the client would fetch direct messages by polling http://moeffju.net/twitter-proxy/direct_messages.json. Or you could pass through everything, but merge Summize results into the /replies feed.
Or you could simply set the endpoint to http://fanfou.com/ and instantly turn your Twitter client into a Fanfou client.
I would further suggest to extend the Twitter API with a public function to query available methods, but as a basic first step, please, Twitter clients, allow me to define my own endpoint base URL.
Twitterific already lets you define your own end-point, and I’ve been thinking about this as well. Rather than someone release a twitter clone to compete, just release a twitter API proxy as you detail above.
i don’t think that this is the right approach, twitter’s scalability issues are result of deploying the wrong technology, rails was not developed to run such a messaging service – erlang was.
i guess we can safely assume that fanfou is using the same platform, and sooner or later it will run into the same problems.
i think we shouldn’t try to figure out ways how we can live with the shortcomings of ror, instead we should use the right technology in the first place.
i am currently playing with twoorl, and open source twitter clone written in erlang, using the erlyweb framwork and yaws, unfortunately i am an erlang noob, but i will dive into it as i am convinced that it is worth the effort.
so i vote for twoorl, it is open source and it is up to us to make it a better twitter for the sake of everybody.
@marcuhlig: Yes, but even that would gain from having a Twitter-style API codified that you could use from any client easily. The backend doesn’t matter so long as your API speaks twitterese.