Month: July 2008

Vor zwei Tagen – am Montag – habe ich unsere Firmenmails zu Google Apps for your Domain umgezogen. Unser bestehender Mailhoster bot kein IMAP an, und so standen wir vor der Entscheidung, die gesamte Domain oder nur den Mail-Teil umzuziehen, und falls, wohin. In Frage kamen ein eigener Server, Google Apps, oder eine Drittanbieter.

Heute schon bereue ich es, mich für Google Apps entschieden zu haben. Die Migration war eher holprig – Google bietet weder an, bestehende Google-Kalender oder Mail-Konten zu übernehmen, noch funktionieren ihre Tools wie z.B. der Google E-Mail Uploader: Unter Windows Vista brach die Installation einfach ohne Meldung ab, nach dem achten Mal war es dann aber installiert; unter Windows XP x64 startet die Installation nicht einmal (“Fatal error 2”). Dank Ruby war die Mailmigration dann vergleichsweise schnell lösbar, dank ICS konnten auch die Kalender – mühsam zwar, aber immerhin – portiert werden.

Langsam pendelte sich also alles ein, dann geschah das, was (bei) Google eigentlich nie geschehen sollte: Der “Temporary Error (502)”. Beim Versuch, auf meine Mail per Webinterface zuzugreifen, erhalte ich nur die lapidare Meldung “We’re sorry, but your Google Mail account is currently experiencing errors.” mit der Bitte, es doch “in a few minutes” nochmal zu versuchen.

Diese Fehlermeldung hält sich nun seit über fünf Stunden. Fünf Stunden, in denen ich nicht an meine Firmenmails komme. Selbst der IMAP-Server meldet nur * BYE System Error und trennt die Verbindung. Ganz abgesehen davon, dass das für mich persönlich und die Firma einfach extrem nervig und unakzeptabel ist, finde ich auch und vor allem, dass das Google eigentlich unwürdig ist. Diese Leichtfertigkeit, mit der das Vertrauen der Benutzer verspielt wird, sehe ich allerdings in letzter Zeit vermehrt bei Google: Sei es, dass sich jeder fragt, was das mit Jaiku soll, die gehäuften Ausfälle bei Google Mail und Google Talk, oder dass immer mal wieder Dienste oder Programme einfach eingestellt werden.

Google, that’s ridiculous.

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.