Ich habe mir heute mal ein paar Gedanken zum Problem von Twitter und Synchronisierung gemacht. Ich formuliere jenes Problem kurz noch Mal, damit wir alle wissen, wovon ich rede:
Viele benutzen Twitter nicht nur auf ihrem mobilen Gerät (iPhone, …), sondern auch an einem Computer (Mac/PC), doch der Status der einzelnen Tweets wird nicht zwischen beiden Geräten synchronisiert. Also muss ich auf dem iPhone alle Tweets, Mentions und Direct Messages nochmal überscrollen oder als gelesen markieren, die ich vielleicht schon vor Stunden auf meinem Mac gelesen habe und umgekehrt. Jedes Mal, wenn man das Gerät wechselt der gleiche Ärger.

Bisher haben uns Firmen wie naan studios (Echofon) und atebits (Tweetie) vertröstet mit einem selbstgebackenen Sync zwischen mobiler Anwendung und Desktop-Client, der bald kommen sollte – aber bisher kam noch nichts überzeugendes – Echofon synct zwar, ist aber noch nicht aus der Beta raus.

Was ist so schwer daran, wenn ich mal ganz naiv fragen darf? Und warum muss da jeder seine eigene Lösung für das Problem finden? Warum muss ich dann bei der Wahl meiner Anwendungen Desktop- und Mobile-Anwendung vom gleichen Hersteller nehmen, wenn ich vielleicht mischen möchte? (Tweetie auf dem iPhone und Echofon auf dem Mac, o. ä.)
Ich habe mir eine mögliche Lösung überlegt, die noch nichtmal eine Änderung seitens der Twitter-API erfordert. Wenn irgendjemand da draußen ein Grund einfällt, warum man das Twitter-Sync Problem nicht so lösen sollte oder könnte, würde ich das wirklich gerne hören.

Machen wir uns einmal zunutze, dass jeder Tweet und jede Direktnachricht (DM) einen unique identifier (UID) hat – die UID hatte zur Twitpocalypse einen kurzen Augenblick im Rampenlicht. Wichtig an dieser UID ist, dass sie inkrementell vergeben wird und zwar zeitabhängig. Wenn ich zwei Tweets vergleiche kann ich an ihrer UID sehen, welcher als erstes und welcher als zweites verschickt wurde. Im Moment liegt diese UID irgendwo um die 6.300.000.000 (siehe http://www.twitpocalypse.com/). Nun ist es von entscheidender Bedeutung, dass unsere Synchronisierung schlank ist, also sollen die übertragenen Daten möglichst klein sein.
Als Integer kann man die UID schon nicht mehr behandeln, deswegen stecken wir sie einfach in einen string (Zeichenkette), in der jedes Zeichen ein Byte groß ist. Im Moment kämen wir mit 10 Byte pro UID aus, sagen wir mal 16 Byte, damit wir für die Zukunft gerüstet sind.

Wir machen uns nun weiter zunutze, dass Tweets in einer zeitlichen Reihenfolge bei den Clients eintreffen (also mit immer steigender UID) und sie in der gleichen Reihenfolge auch gelesen werden. Dies gilt nicht nur für die eigene Timeline, sondern auch für Mentions und Direktnachrichten.

Jetzt legen wir mal eine mini-Datenbank an. Diese Datenbank besteht aus mehreren Einträgen, die einem Bezeichner eine UID zuordnen. Diese UID spezifiziert den letzten gelesenen Tweet. Also brauchen wir einen Eintrag für die persönliche Zeitleiste (und vielleicht noch jede gespeicherte Suche) und einen für die Mentions, denn es kann ja sein, dass man eine Mention von jemandem kriegt, den man nicht in seiner Zeitleiste hat. Jetzt brauchen wir noch einen Eintrag für jede DM-Konversation und fertig ist der Lack.
Für den Bezeichner reichen 15 Byte, da Twitter nur Benutzernamen von maximal 15 Zeichen zulässt. In einer Datenbank benötigt man dann noch ein spezielles Zeichen, um Bezeichner und Wert voneinander zu trennen, also kommen wir auf 15+1+16 = 32 Byte pro Eintrag.

Weil ich vorhin von Schlankheit gesprochen habe, seien hier ein paar theoretische Größen für die Datenbank gegeben, die sich folgendermaßen berechnen lassen: (2+n)*32 wobei n die Anzahl der DM-Konversationen und der gespeicherten Suchen ist. Jeder Benutzer braucht mindestens 2 Einträge, einmal für die Timeline und einmal für die Mentions.

• minimale Größe (n=0): 64 Byte
• n=100: 3,19 KB
• n=500: 15,69 KB
• n=1.000: 31,31 KB
• n=10.000: 312,56 KB
• n=100.000: 3,05 MB

Man müsste schon eine Twitter-Berühmtheit sein, die von jedem seiner Follower mindestens eine DM bekommen hat, damit diese Datenbank eine bemerkenswerte Größe annimmt.
Mit ein paar Kniffen wie time-to-live für DM-Einträge und Kompression ließe sich das sicher noch schlanker machen, aber alles in allem wären die Übertragungskosten sehr gering.

Einziges Problem bei dieser Lösung ist das Lagern dieser Datenbank. Der optimale Ort wäre Twitter selbst, somit wäre der Zugriff am einfachsten und die Einträge wären vor unbefugter Änderung geschützt.
Aber rein theoretisch könnte man diese Datenbank hinlegen wo man möchte (Dropbox vielleicht?) – so lange jeder Client eine Möglichkeit hat, den Ort der Datenbank einzutragen und so lange die Datenbank vor unberechtigten Zugriffen geschützt ist.

Schon haben wir einen Twitter-Sync, der nicht nur cross-Platform sondern auch cross-Client und cross-Entwickler funktionieren kann – und twitter.com musste nichtmal einen Finger krumm machen (es sie denn, sie besäßen die Güte, die Datenbanken bei sich zu lagern)!
Wenn jetzt ein Twitter-Client gestartet wird, läd er sich die Datenbank des Benutzers herunter und läd, wie gewohnt, die letzten Tweets. Anstatt aber so zu tun als wären alle geladenen Tweets neu, würde der Client in der Datenbank nachschauen, welcher Tweet beispielsweise in der Timeline zuletzt gelesen wurde und würde dann zu diesem Tweet scrollen. Gleiches würde dann bei den Mentions und den DMs passieren.
Ähnlich einem Mail-Programm könnte eine Synchronisierung mit der Online-Datenbank alle paar Minuten, spätestens aber bei Programm-Start und -Ende erfolgen. Selbst wenn ich auf iPhone und Mac parallel lese und schreibe wäre eine Konfliktbehandlung trivial: die größere UID gewinnt.

Soviel zu meinen Überlegungen. Und jetzt nochmal die Frage vom Anfang: was ist so schwer daran? Warum dauert das so lange?