Subject: Kommunikation (2)
From: Boris Kraut <[email-masked]>
To: undisclosed-recipients: ;
Date: Tue, 18 Jan 2011 01:06:00 +0100

Ich komme in letzter Zeit nicht mehr ganz so haeufig dazu, hier
ein wenig zu schreiben, da ich mich momentan mal wieder auf die
Pruefungszeit vorbereite. Wenn ich mal etwas Abstand vom Lernen
brauche, beschaeftige ich mich immer noch mit dem grossen Haupt-
thema "Kommunikation". Hier einige -- nun wirklich technische
--  Gedanken:

Ein Kernstueck der Unix-Philosophie ist, dass jedes Programm
eine Sache erledigen soll, die dann aber besonders gut. Einige
mag es daher verwundern, dass ich schon seit einiger Zeit meine
Feeds in meinem Mailclient lese. Was sich auf den ersten Blick
beisst, ergibt auf den zweiten doch einen gewissen Sinn, denn
die Aufgabe, die mein MUA erfuellt ist "Nachrichten anzeigen
und ggf. an weitere Programme weitergeben" --- und Nachrichten
haben sich in der letzten Zeit nicht wirklich geandert:

== eMail ==

From: me <me@localhost>
To: you <you@localhost>
Date: Mon, 10 Jan 2011 12:40:57 +0000
Message-ID: <[email-masked]>
Subject: Foobar

Hier steht eine Nachricht.

== Atom ==

<entry>
        <author>
                <name>John Doe</name>
        </author>
        <title>Atom-Powered Robots Run Amok</title>
        <link href="http://example.org/2003/12/13/atom03" /> 
        <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
        <updated>2003-12-13T18:30:02Z</updated>
        <content>Some text.</content>
</entry>

Auch wenn ich hier nicht ganz konform mit dem RFC gehe, erkennt
man doch, dass die eigentliche Information die selbe ist. Bei
Feeds kennt man noch einige weitere Elemente, die potentiell
mehr Informationen bieten koennen, dabei wird aber oft vergessen,
dass auch die normale Mail sehr viele Header-Felder kennt, die
leider kaum noch genutzt werden -- und man hat immer noch die
Moeglichkeit, eigene Header-Informationen anzufuegen.

Prinzipiell hat sich also an der eigentlichen Nachricht nichts
geaendert (ja, bei allen Formaten gibt es sicherlich Spezial-
faelle, die nur im jeweiligen Format moeglich sind, aber diese
sind in der freien Wildbahn nicht haeufig und kommen in meiner
alltaeglichen Anwendung nicht vor) getan, nur die Form hat sich
geaendert. Auch wenn man noch drei weitere Beispiele betrachtet,
erkennt man, dass alle diese Formate den selben Inhalt trans-
portieren und man eigentlich jedes in eins der anderen ueber-
fuehren koennte:

== XMPP ==

<message from=[email-masked]'
         to=[email-masked]'
         xml:lang='en'>

    <body>Art thou not Romeo, and a Montague?</body>

</message>

== IRC ==

PRIVMSG #testchannel Inhalt

== TALK ==

Message from [email-masked] on pts/3 at 00:23 ...
Inhalt

Ich treffe hier wie gesagt noch keine Aussage darueber, welches
Protokoll nun besser ist, mir geht es prinzipiell erstmal um
den Infromationsgehalt einer Nachricht in den verschiedenen
Formaten, der nahezu gleich ist. Von daher scheint es mir doch
eine Ueberlegung wert zu sein, ob man das nicht etwas zusammen-
fuehren koennte und wenn ja, in welchem Format.

Ein sehr populaeres Beispiel ist ein Format, das zwar selbst
standardisiert ist, aber im Gegensatz zu den vorherigen weniger
Aussagen ueber den Inhalt trifft: HTML. 

Webdienste wie Twitter, Foren oder soziale Netzwerke sind nicht
ohne Grund so populaer und das Web hat ja schon gezeigt, dass
es durchaus Mails oder News -- letzteres hier straeflicherweise
vernachlaessigt -- ebenfalls adequat darstellen kann.

Auch wenn der Einsatz von Webtechnologien eigentlich nicht so
sehr zu meiner bisherigen Haltung passen mag und ich das immer
noch sehr kritisch sehe, ist es wert, den Gedanken mal etwas
weiter zu spinnen. Wie waere es, wenn man von aussen alle
gewuenschten Formate entgegennimmt, aufbereitet und auf einem
"Unified User Interface" in Form einer Website ausgibt? Diese
Website muesste natuerlich auch von einem Textbrowser bedienbar
sein und um wirklich nuetzlich zu sein, muesste man einen
einfachen Weg fuer Antworten finden, aber das ist ja durchaus
machbar, und es wurde schon gemacht...

... so nutzt Google intern wohl ein voellig anderes System,
auch wenn sie nach aussen XMPP, SMTP oder IMAP  sprechen. Auch
gibt es mit PSYC [1] ein Projekt, dass eine Vielzahl von
Gateways anbietet, weil sie erkannt haben, dass es besser ist
den Usern den Umstieg so einfach wie moeglicht zu machen. Der
User will erstmal das weiterhin einsetzen, was er gewohnt ist:
Mail, IRC, XMPP, was auch immer. Dabei ist es im egal, was
unter der Haube nun tatsaechlich gesprochen wird.

Ich schweife ein wenig in die Protokoll-Ebene ab, aber ich
wollte ja Eigentlich noch ein paar Worte ueber das Interface
verlieren. Prinzipiell gefaellt mir hier das Layout von Soup
[2] schon sehr gut und hier sieht man auch, wie unterschiedliche 
Inhalte zusammenfuehren kann. Auch Twitter ist in diesem Punkt
nicht schlecht.

Ich selbst habe schon ein ungefaehres Design vor Augen und habe
einfach mal erste Tests mit XHTML5 gemacht. XHTML5 bietet mir
zum einen sehr nette Tags, die ich bisher vermisst habe -- so
z.B. 'article' oder 'figure' -- aber auch die Moeglichkeit
unkompliziert ander XML-Formate wie Atom oder XMPP einzufuegen.
Eigentlich. Waehrend Atom relativ problemlos funktioniert,
klappt das bei XMPP erstmal gar nicht und mir wurde klar, warum
ich XML nicht mag. Bei XMPP sehr stoerend war, dass es sich
in der Praxis einen Dreck um Namespaces kuemmert und dass es
KEIN XML ist. Was? Ja! XMPP nutzt zwar eine sehr grosse Teil-
menge von XML, aber sehr strickte Standardwerkzeuge fuer XML
funktionieren nicht. Schluckauf gab es bspw. bei XML-Kommentaren
im Stream oder bei nicht escapten ">" -- das ist zwar eklig,
aber XML erlaubt diese Zeichen!

Momentan bin ich von der ganzen Sache derart angewidert und
genervt, dass ich da nicht weiter dran arbeiten werde (das
haette mir in der Klausurzeit gerade noch gefehlt), aber die
Idee hat schon etwas. Eventuell kann man eine von den bereits
vorhandenen System-Nachrichten-Diensten dafuer verwenden, aber
dann Artet das ganze noch mehr aus und ich muss mich genau mit
dem Zeugs auseinander setzen, dass mir immer wieder zeigt, wie
schlecht die ganze Computer-Welt ist. Seufz. Aber eventuell
wuerden die "normalen" Nutzer so etwas lieber nutzen? Vielleicht
waere es ein Schritt, um der schleichenden "Proprietarisation of
Communication" [3] entgegen zu wirken?

> I'm talking about the messaging systems built into sites like
> Facebook and LinkedIn. On several occasions recently, friends
> have chosen to get back in touch with me via one of these rather
> than by email. Another friend recently finished a conversation
> with a third party by saying "Facebook me"; when I asked her
> why she didn't just use email, she said "Oh, Facebook is so
> much easier".
> 
> [...]
> 
> But this is, nevertheless, a bad trend. It would be terrible
> if email were to descend into something like the multiple
> incompatible domains [Anmerkung: We have been there! Schonmal
> was von AOL gehoert?] that afflict instant messaging - the
> heroic efforts of gateway providers and multi-protocol clients
> notwithstanding. Will we one day need accounts on every social
> website in order to stay in touch? Will someone need to write
> a Facebook/MySpace mail gateway?
>
> [...]
>
> Making real email easier to use is a first step.

Mit diesem Schlusswort moechte ich mich fuer heute verabschieden,
die Idee an sich ist nicht gestorben, aber es wird wohl am Ende
zu ein paar XMPP-und-Atom-zu-Mail-Scripts hinauslaufen. Wobei ich
mich bei einigen meiner Artikel schon ueber mehr Moeglichkeiten
aus dem HTML5-Baukasten freuen wuerde... Seufz. Es bleibt also
spannend. Nichts ist entschieden.

[1] http://www.psyc.eu/
[2] http://www.soup.io/
[3] http://weblogs.mozillazine.org/gerv/archives/2007/06/the_proprietarisation_of_email.html