Subject: [.plan] Thinclients, Synchronisation und was das mit "mailto" zu tun hat
From: Boris Kraut <[email-masked]>
To: undisclosed-recipients: ;
Date: Thu, 30 May 2013 12:33:45 +0200

Scharzfahren? Da hat deine Aktion mit Hunspell und nochmaligem
Durchlesen wohl nichts gebracht, oder? Nun, nicht ganz. Ich habe
zwar mein System entsprechend umgestellt, aber ich schreibe seit
einiger Zeit nicht damit, sondern ueber meinen Mailclient. Doch
der Reihe nach:

Es gab eine Zeit, in der man aufgrund der technischen Gegeben-
heiten auf ein Client-Server-System setzte: Ein grosser, teurer
Rechner mit mehreren Nutzern, mit mehreren Terminals. Und es
waren wieder neue technische Gegebenheiten, die es damals ueber-
haupt erst moeglich machten, ueber einen "Fatclient" nachzudenken.

Heute versuchen allzuviele Unternehmen uns diese Entscheidung
abzunehmen und das ohne eine wirkliche Diskussion. Die Technik
hat sich nicht geandert Fat-Clients (oder gar keine "Clients" mit
gleichberechtigten Peers -- jeder ist Client und Server) sind
weiterhin machbar, ja sogar machbarer denn je. Und trotzdem be-
geben sich die meisten ohne Nachdenken in eine hierarchische
Client-Server-Struktur. Das liegt ja auch auf der Hand, gerade
in Zeiten von zig mobilen Endgeraeten, die alle synchronisiert
werden wollen, auf grosse Datensilos zu setzen.. oder etwa nicht?

Vergessen wir all das Client-Server- und Thinclient-Geschwafel.
Weder geht es um eine absolute Ja/Nein-Entscheidung mit nur einer
"Wahrheit", noch versteht irgendjemand, was damit gemeint ist. Die
Grundfragen sind doch recht simpel..

Wo lagern meine Daten?
Wo lagern meine Programme?
Wo findet die Verarbeitung statt?

.. und darauf aufbauend:

Wem vertraue ich?
Welche Programme und Protokolle nutze ich ggf.  zum Synchronisieren?

Selbst wenn man unter der Praemisse lebt, dass ein zentrales Daten-
silo "der richtige Weg" ist -- ganz egal ob das jetzt bei Google und
Co oder auf einem Homeserver liegt -- bleibt immer noch die Protokoll-
Frage. Klar, ich nehme lieber IMAP, CalDAV, CardDAV, WebDAV, HTTP usw.
bevor ich proprietaere Einzelloesungen nutze, aber warum brauchen wir
so eine Masse fuer ein mehrfach geloestes Problem? Beliebige Text-
dateien und ein paar Binaries synchronisiert zu bekommen ist wirklich
kein Hexenwerk mehr.. auch mit Versionierung und allem Pipapo.

Und selbst wenn ich eins der oben genannten Protokolle einsetzen will,
warum muss das jedes Programm unterstuetzen? Programme haben bereits
eine universelle Ein/Ausgabe: Sie koennen Dateien lesen und schreiben.
Woher diese kommen, wohin sie gehen oder ob sie ueberhaupt "lokal"
vorhanden sind, spielt keine Rolle. Man braucht nur einmal den Auf-
wand betreiben, die ueber das jeweilige Protokoll verfuegbaren Daten
auch im lokalen Filesystem zu repraesentieren (und Aenderungen daran
auch remote umzusetzen).

Seufz. Plan9. Seufz.

Alternative kann man natuerlich auch bewusst alles "lokale" halten
und die Synchronisierung dieser Arbeitskopien in einem zweiten Schritt
erledigen, z.B. ueber die verschiedenen DVCS oder rsync und Konsorten.

Wie dem auch sei, fuer den Otto-Nutzer ist die Entscheidung wohl vor-
erst gefallen, doch wie beantworte ich mir die obigen Fragen? Fest
steht, dass ich

 a) Daten, Programme und Verarbeitung auf dem selben Geraet haben
    will und
 
 b) dieses Geraet natuerlich unter meine Kontrolle steht.

Die noch ausstehende Entscheidung ist aber, ob ich "Internet" schon
als "ueberall verfuegbar" ansehen kann. Wenn ja, dann tendiere ich
zur bekannten Loesung: Kleiner, eigener Homeserver mit relativ
dummen Clients. Konkret nen SSH-Client, ein paar Tools um sich
durch Proxies und Firewalls zu wuehlen und ggf. die ein oder anderen
grafischen Programme wie eigener Browser, PDF-Reader und so.

Ist damit zu rechnen, dass ich haeufiger kein Internetzugang habe,
dann muss ich logischerweise alles lokal haben und ggf. "remote"
nur einen Backupplatz vorhalten.

Aber ganz egal, wie diese Entscheidung ausfaellt -- ich will eher
ersteres, aber die Praxis zwingt mich wohl zu zweitetem -- stellt
sich auch noch der Client-Hardware: Tablet, Notebook oder reicht
ein USB-Stick mit Software (bzw. mit dem ganzen OS und den Daten?).

Ich bin unschluessig.

Aber was hat das ganze nun mit dem Schreiben von Artikeln zu tun?
Nun, da ich immer weniger dazu komme, mir explizit Zeit zum Schreiben
zu nehmen, liegen auf meinem Notebook immer ein gnazer Stapel von
Entwuerfen und Ideen rum. Zwar konnte ich die auch unterwegs be-
arbeiten, aber das eigentliche Absenden war nur per SSH oder eben
am Abend zuhause moeglich -- wo ich es dann meist vergessen hatte
oder mir ide Lust fehlte. Haeufiger als einen SSH-Zugang habe ich
aber zumindest einen Mailaccount und das Web zur Verfuegung; das
koennte man ja durchaus zum Versenden nutzen. Problem: Textdateien
als Draft-Message zu nutzen scheint immer unpopulaerer zu werden,
doch erstaunlich haeufig gibt es mailto-URL-Handler, die entweder
das jeweils lokal installierte und konfigurierte Mailprogramm nutzen
oder einen Webmailer oeffnen (und mal mehr oder weniger die noetigen
Header-Felder aus der mailto-URI uebernehmen). Von daher habe ich
beim Generieren meiner Postings einen Zwischenschritt eingebaut,
der nicht sofort Drafts generiert, sondern eine mailto-URI. Bin ich
daheim, wird diese sofort wieder in eine Textdatei umgewandelt, in
meinen Draft-Folder gelegt und mein MUA gestartet. Unterwegs wird
die URI direkt an den jeweiligen MUA weitergegeben -- derzeit ist
das k9-Mail, SquirrelMail oder Thunderbird. Das ganze funktioniert
auch aus dem Browser selbst ganz gut. Mit etwas JavaScript -- nur
boese, wenn es aus Fremdquellen kommt -- lassen sich auch Book-
marks ganz angenehm und fast automatisiert per Mail verschicken.