Twacbak nutzt noch das bisherige Verfahren, bei dem über HTTP Basic Authentication Name und Kennwort mittels Base64 verscheiert übertragen werden. Dabei beruhigt höchstens die mögliche Übertragung per SSL. Das Modul zur direkten Kommunikation habe ich nicht selbst entwickelt. Statt dessen passte ich die Python Twitter Tools (PTT) an meine Bedüfnisse an.

Der 30.06.2010 näherte sich, besonders letzte Woche. Der Author der PTT scheint gerade OAuth zu implementieren, aber ob er bis zum 30.06.2010 fertig wird, bleibt offen. Und dann bräuchte ich ja noch Zeit, die Änderungen in Twacbak zu integrieren. Eine einfache Risikoabschätzung zeigt: besser etwas anderes.

OAuth ist kein triviales Protokoll. Es gibt für die unterschiedlichsten Szenarien Möglichkeiten der Anbindung. In den meisten Beispielen wird davon ausgegangen, dass die Anwendung, die auf Twitter zugreifen möchte, selbst eine für jeden zugänglich Webanwendung ist. Twacbak ist aktuell eine reine Konsolenanwendung. Und selbst wenn Twacbak einmal eine Webanwendung wird, würde es bei mir nur im lokalen Netz laufen.

Das ist die Situation: Twacbak muss bis Ende Juni 2010 an OAuth angepasst werden, OAuth ist ein komplexes Protokoll, mein bisheriges Modul zur Kommunikation mit Twitter unterstützt kein OAuth.

Mitte November 2009 stolperte ich über Tweepy. Damals war es nicht besonders ausgereift, kein Vergleich zu PTT. Zum Glück hatte ich es in meinem Brain einsortiert und schaute es mir letzte Woche noch einmal im Detail an. Etwas anders aufgebaut als PTT unterstützt es nun recht ausgereift OAuth.

Bleibt das Problem, wie man sich in einer Konsolenanwendung bei Twitter über OAuth authentifiziert. Die Beispiele im Web gaben nicht viel her. Ein wenig herumexperimentieren, Python’s REPL half immens, kam heraus, dass es recht einfach ist:

auth = tweepy.auth.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
auth_url = auth.get_authorization_url()
webbrowser.open(auth_url)
pin = getline('Enter PIN: ').strip()
if pin:
    access_token = auth.get_access_token(pin)
    # sichere access_token.key und access_token.secret für zukünftige
    # Zugriffe, z.B. in einer Datenbank

Die Werte für CONSUMER_KEY und CONSUMER_SECRET erhält man nach der Registrierung einer Anwendung bei Twitter. Mittels get_authorization_url() erhält man von Twitter eine URL, unter der ein Benutzer die Anwendung authorisieren kann. Nach der Authorisierung erhält der Benutzer auf der Webseite eine PIN, die er dann in der Konsolenanwendung angeben muss. Diese dient dazu, dass die Anwendung über Twitter ein sog. Access Token erhält. Damit authentifiziert sich die Anwendung später gegenüber Twitter. Das Access Token ist benutzer- und anwendungsspezifisch und damit wesentlich sicherer als ein Kennwort.

Der spätere Zugriff ist dann wieder einfach:

auth = tweepy.auth.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
# lese key und secret aus Datenbank
auth.set_access_token(key, secret)
api = tweepy.API(auth, parser=tweepy.parsers.JSONParser())

Über das Objekt api können dann die Methoden der Twitter-API authentifiziert aufgerufen werden. Fertig.

Fertig? Nein. Tweepy hat eine leicht andere Philosophie als PTT. Aber zum Glück ist Python nicht statisch typisiert. Sonst hätte ein Großteil von Twacbak angepasst werden müssen (Ja, ich weiß: geringere Kopplung …). Dank Duck Typing, eines der besonders angenehmen Merkmale von Python, und der guten Konfigurierbarkeit Tweepy’s musste ich nur einige wenige Stellen anpassen. Nach kurzer Zeit war ich dann wirklich fertig mit der Umstellung.

Twacbak arbeitet nun mindestens so gut wie vorher. Subjektiv scheint es sogar schneller mit Twitter zu kommunizieren. Aber das kann auch daran liegen, dass Twitter die Kommunikation mittels OAuth bevorzugt abwickeln könnte.

Jetzt kann ich wieder in Ruhe darüber nachdenken, wie sich Twacbak weiter entwickeln soll. Vermutlich in Richtung Webanwendung ;-)

Im Unterschied zu Twacbak ist Twitterbak mit Hilfe von Perl und PHP implementiert. Der Perl-Code dient dazu Twitter regelmäßig per API abzufragen und die Ergebnisse abzuspeichern. Mit PHP wird ein web-basierter Dienst implementiert, um die Ergebnisse anzuzeigen und zu durchsuchen. Schwerpunkt von Twitterbak ist das Archivieren der eigenen Tweets.

Ist Twitterbak eine Konkurrenz zu Twacbak?

Auf jeden Fall. Eine gute dazu.

Das Profil von Twitterbak ist klar: Datensicherung. Wohin die Reise mit Twacbak hingehen wird, ist mir dagegen noch nicht klar.

Was gibt es an Ähnlichkeiten? Beide wollen die Ergebnisse von Twitter-Aktivitäten längerfristig sichern, beide nutzen dazu SQLite als interne Datenbank. Beide sichern die eigenen Tweets, die direkten Nachrichten und die sog. Mentions, d.h. Tweets, in denen der eigene Account erwähnt wird. Beide sollen periodisch im Hintergrund, z.B. als Cron-Job, ablaufen.

Was kann Twacbak darüber hinaus? Twacbak kann auch die gesamte Timeline sichern, d.h. alle Tweets aller Account, denen man selbst folgt. Es werden die Favoriten gesichert und, ganz wichtig, alle Friends und Follower. Ich weiß, wovon ich spreche. Die Liste derjenigen denen man folgt ist ein fast so wertvolles Asset, wie die eigenen Tweets. Nebenher speichert Twacbak die Friend/Follow-Historie, denn es gibt immer wieder welche, die einem abwechselnd folgen und wieder nicht folgen. Damit ist Twacbak nicht nur ein Werkzeug zum Sichern der Twitter-Aktivitäten, sondern unterstützt diese auch. Mit Twacbak können sebst auch Tweets gesendet werden, Re-Tweets auf Basis von Schlüsselworten werden unterstützt, auch das Folgen per Kommandozeile geht.

Viele der anderen Unterschiede sind Geschmackssache. Ob ich nun das Ganze über eine Konfigurationsdatei steuere oder ob die Daten in der Datenbank selbst abgelegt werden: jeder wird für beides Vor- und Nachteile finden. Ditto für Änderungen am Quellcode selbst und einige Befehlsoptionen mehr gegenüber der Wahl für eine kleine Skriptsprache. Letztens Endes Firlefanz für einen Vergleich.

Natürlich kann das eine oder andere auch schnell von Twitterbak implementiert werden. Auch die größere Fehlertoleranz, wenn Twitter mal wieder nicht verfügbar ist. Darauf freue ich mich.

Ich habe für Twacbak die Anregung aufgenommen, die kurzen URL zu ermitteln, die sich hinter den Twitter-typischen Short-URL’s (z.B. via bit.ly) verbergen. Das gleiche gilt für Bilder. Nebenbei, dank der Python-Bibliotheken (“Batteries included“) geht das Ganze leichter und weniger fehleranfällig von der Hand. (Die Spitze musste sein, ich nehm das aber nicht zu ernst ;-) )

Über den Artikel habe ich mich sehr gefreut. Bestätigt er doch, wie sinnvoll es ist, selbst für die Sicherung der eigenen Daten zu sorgen und sich nicht immer nur irgendwelchen obskuren Web-Diensten anzuvertrauen. Ich werde die Entwicklung von Twacbak im Rahmen meines knappen Zeitbudgets vorantreiben und immer mal nach nebenan zur Konkurrenz schielen.

Die belebt nämlich auch den eigenen Geist.

Also, was sind (meine) Anforderungen?

Funktionalität

• Sichern aller grundlegenden Daten eines Twitter-Accounts, wie:
  • Benutzerdaten (Name, Location, eigene URL, Bio, … so wie sie im Profile / Setting angegeben werden),
  • alle eigene Tweets,
  • Favorites,
  • gesendete Nachrichten,
  • empfangene Nachrichten,
  • Liste der Friends, d.h. der Accounts, denen man folgt,
  • Liste der Follower, d.h. die Account, die einem folgen.
• Sichern von nützlichen Zusatzinformationen:
  • Wann ist mir wer gefolgt, wann hat er mich aus seiner Liste gelöscht?
  • Wann bin ich jemanden gefolgt, wann habe ich das Verfolgen aufgegeben?
  • Was haben meine Friends so getwittert?
  • Wenn jemanden eine Antwort getwittert hat, auf welchen Tweet welchen Benutzers bezog sich diese Antwort?
• Die gesammelten Daten sollen auf den Bildschirm / in eine Datei ausgegeben werden können.
• Darüber hinaus sollen folgende Berichte (Bildschirm / Datei) ausgegeben werden:
  • Liste der Accounts, die kürzlich das Verfolgen eingestellt haben
  • Detailinformationen zu Accounts, z.B. wann bin ich gefolgt, wann wurde meinem Account gefolgt, wann wurde das Verfolgen eingestellt und wieder aufgenommen, …
  • Durchsuchen der Tweets nach bestimmten Begriffen.
• Sobald von Friends Tweets mit einem definierten Hashtag erscheinen, sollen diese Retweetet werden.
• Eigene Tweets sollen auf einem anderen Account gespiegelt werden.
• Gespeicherte Informationen zu Accounts sollen regelmäßig aktualisiert werden, z.B. einmal pro Woche.

Technisches

• Die Daten sollen so abgespeichert, dass diese auch separat auswertbar sind.
• Twacbak soll regelmäßig ohne Benutzerinteraktion die Daten von Twitter einsammeln können.
• Es soll eine Lösung für einen Account erstellt werden.  Twacbak soll nicht für beliebig viele Accounts Daten sammeln.
• Es sollen beliebige Microbloggingdienste unterstützt werden, welche die Twitter-API bereitstellen. Neben Twitter ist dies z.B. identi.ca.
• Twacbak soll im Normalfall einmal pro Stunde ablaufen und dabei max. 50 Aufrufe der API tätigen.
• Die Software soll so weit es geht platformunabhängig sein. Auf jeden Fall soll die Software unter Windows und unter Linux ablaufen.

Als Heimat kommen auch diese Seiten in Betracht. Dann könnte ich aber entweder “nur” das gesamte Paket zum Download anbieten oder ich müsste hier Software installieren. Aber es gibt ja Dienste, welche die Softwareentwicklung unterstützen. De facto gibt es die Wahl zwischen SourceForge.net oder Google Code. Ich habe mich für SourceForge.net entschieden, weil es da einige Dienste gibt, die ich immer schon mal ausprobieren wollte: Mercurial als verteiltes Versionskontrollsystem (kann Google Code auch) und Trac (kann Google Code m.E. nicht). Beide wären auch Kandidaten für meine Veranstaltung “Projektstudie Softwareentwicklung” ;-).

Somit ist die Heimat von Twacbak gefunden.

Bleibt noch die Frage der Lizenz. Open Source sollte sie sein, von abgeschlossenen Systemen halte ich nicht zu viel. Die GPL ist mir zu viral (und einschränkend), MIT & Co. zu offen. Als Lizenz habe ich (vorläufig) die Apache License, Version 2.0 definiert.

Ja, ich weiß. Langsam sollte ich die Anforderungen definieren. *g