1 From: Boris Kraut <krt@nurfuerspam.de>
\r
3 Date: Tue, 18 Jan 2011 01:06:00 +0100
\r
5 Message-ID: <20110118000600.f18Wya@silberbruch>
\r
8 To: undisclosed-recipients: ;
\r
9 Subject: Kommunikation (2)
\r
11 Ich komme in letzter Zeit nicht mehr ganz so haeufig dazu, hier
\r
12 ein wenig zu schreiben, da ich mich momentan mal wieder auf die
\r
13 Pruefungszeit vorbereite. Wenn ich mal etwas Abstand vom Lernen
\r
14 brauche, beschaeftige ich mich immer noch mit dem grossen Haupt-
\r
15 thema "Kommunikation". Hier einige -- nun wirklich technische
\r
18 Ein Kernstueck der Unix-Philosophie ist, dass jedes Programm
\r
19 eine Sache erledigen soll, die dann aber besonders gut. Einige
\r
20 mag es daher verwundern, dass ich schon seit einiger Zeit meine
\r
21 Feeds in meinem Mailclient lese. Was sich auf den ersten Blick
\r
22 beisst, ergibt auf den zweiten doch einen gewissen Sinn, denn
\r
23 die Aufgabe, die mein MUA erfuellt ist "Nachrichten anzeigen
\r
24 und ggf. an weitere Programme weitergeben" --- und Nachrichten
\r
25 haben sich in der letzten Zeit nicht wirklich geandert:
\r
29 From: me <me@localhost>
\r
30 To: you <you@localhost>
\r
31 Date: Mon, 10 Jan 2011 12:40:57 +0000
\r
32 Message-ID: <0C531FED0F13F14@foo.bar.local>
\r
35 Hier steht eine Nachricht.
\r
42 <name>John Doe</name>
\r
44 <title>Atom-Powered Robots Run Amok</title>
\r
45 <link href="http://example.org/2003/12/13/atom03" />
\r
46 <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
\r
47 <updated>2003-12-13T18:30:02Z</updated>
\r
48 <content>Some text.</content>
\r
52 Auch wenn ich hier nicht ganz konform mit dem RFC gehe, erkennt
\r
53 man doch, dass die eigentliche Information die selbe ist. Bei
\r
54 Feeds kennt man noch einige weitere Elemente, die potentiell
\r
55 mehr Informationen bieten koennen, dabei wird aber oft vergessen,
\r
56 dass auch die normale Mail sehr viele Header-Felder kennt, die
\r
57 leider kaum noch genutzt werden -- und man hat immer noch die
\r
58 Moeglichkeit, eigene Header-Informationen anzufuegen.
\r
60 Prinzipiell hat sich also an der eigentlichen Nachricht nichts
\r
61 geaendert (ja, bei allen Formaten gibt es sicherlich Spezial-
\r
62 faelle, die nur im jeweiligen Format moeglich sind, aber diese
\r
63 sind in der freien Wildbahn nicht haeufig und kommen in meiner
\r
64 alltaeglichen Anwendung nicht vor) getan, nur die Form hat sich
\r
65 geaendert. Auch wenn man noch drei weitere Beispiele betrachtet,
\r
66 erkennt man, dass alle diese Formate den selben Inhalt trans-
\r
67 portieren und man eigentlich jedes in eins der anderen ueber-
\r
72 <message from='juliet@example.com'
\r
73 to='romeo@example.net'
\r
76 <body>Art thou not Romeo, and a Montague?</body>
\r
83 PRIVMSG #testchannel Inhalt
\r
88 Message from root@myhost.local on pts/3 at 00:23 ...
\r
92 Ich treffe hier wie gesagt noch keine Aussage darueber, welches
\r
93 Protokoll nun besser ist, mir geht es prinzipiell erstmal um
\r
94 den Infromationsgehalt einer Nachricht in den verschiedenen
\r
95 Formaten, der nahezu gleich ist. Von daher scheint es mir doch
\r
96 eine Ueberlegung wert zu sein, ob man das nicht etwas zusammen-
\r
97 fuehren koennte und wenn ja, in welchem Format.
\r
99 Ein sehr populaeres Beispiel ist ein Format, das zwar selbst
\r
100 standardisiert ist, aber im Gegensatz zu den vorherigen weniger
\r
101 Aussagen ueber den Inhalt trifft: HTML.
\r
103 Webdienste wie Twitter, Foren oder soziale Netzwerke sind nicht
\r
104 ohne Grund so populaer und das Web hat ja schon gezeigt, dass
\r
105 es durchaus Mails oder News -- letzteres hier straeflicherweise
\r
106 vernachlaessigt -- ebenfalls adequat darstellen kann.
\r
108 Auch wenn der Einsatz von Webtechnologien eigentlich nicht so
\r
109 sehr zu meiner bisherigen Haltung passen mag und ich das immer
\r
110 noch sehr kritisch sehe, ist es wert, den Gedanken mal etwas
\r
111 weiter zu spinnen. Wie waere es, wenn man von aussen alle
\r
112 gewuenschten Formate entgegennimmt, aufbereitet und auf einem
\r
113 "Unified User Interface" in Form einer Website ausgibt? Diese
\r
114 Website muesste natuerlich auch von einem Textbrowser bedienbar
\r
115 sein und um wirklich nuetzlich zu sein, muesste man einen
\r
116 einfachen Weg fuer Antworten finden, aber das ist ja durchaus
\r
117 machbar, und es wurde schon gemacht...
\r
119 ... so nutzt Google intern wohl ein voellig anderes System,
\r
120 auch wenn sie nach aussen XMPP, SMTP oder IMAP sprechen. Auch
\r
121 gibt es mit PSYC [1] ein Projekt, dass eine Vielzahl von
\r
122 Gateways anbietet, weil sie erkannt haben, dass es besser ist
\r
123 den Usern den Umstieg so einfach wie moeglicht zu machen. Der
\r
124 User will erstmal das weiterhin einsetzen, was er gewohnt ist:
\r
125 Mail, IRC, XMPP, was auch immer. Dabei ist es im egal, was
\r
126 unter der Haube nun tatsaechlich gesprochen wird.
\r
128 Ich schweife ein wenig in die Protokoll-Ebene ab, aber ich
\r
129 wollte ja Eigentlich noch ein paar Worte ueber das Interface
\r
130 verlieren. Prinzipiell gefaellt mir hier das Layout von Soup
\r
131 [2] schon sehr gut und hier sieht man auch, wie unterschiedliche
\r
132 Inhalte zusammenfuehren kann. Auch Twitter ist in diesem Punkt
\r
135 Ich selbst habe schon ein ungefaehres Design vor Augen und habe
\r
136 einfach mal erste Tests mit XHTML5 gemacht. XHTML5 bietet mir
\r
137 zum einen sehr nette Tags, die ich bisher vermisst habe -- so
\r
138 z.B. 'article' oder 'figure' -- aber auch die Moeglichkeit
\r
139 unkompliziert ander XML-Formate wie Atom oder XMPP einzufuegen.
\r
140 Eigentlich. Waehrend Atom relativ problemlos funktioniert,
\r
141 klappt das bei XMPP erstmal gar nicht und mir wurde klar, warum
\r
142 ich XML nicht mag. Bei XMPP sehr stoerend war, dass es sich
\r
143 in der Praxis einen Dreck um Namespaces kuemmert und dass es
\r
144 KEIN XML ist. Was? Ja! XMPP nutzt zwar eine sehr grosse Teil-
\r
145 menge von XML, aber sehr strickte Standardwerkzeuge fuer XML
\r
146 funktionieren nicht. Schluckauf gab es bspw. bei XML-Kommentaren
\r
147 im Stream oder bei nicht escapten ">" -- das ist zwar eklig,
\r
148 aber XML erlaubt diese Zeichen!
\r
150 Momentan bin ich von der ganzen Sache derart angewidert und
\r
151 genervt, dass ich da nicht weiter dran arbeiten werde (das
\r
152 haette mir in der Klausurzeit gerade noch gefehlt), aber die
\r
153 Idee hat schon etwas. Eventuell kann man eine von den bereits
\r
154 vorhandenen System-Nachrichten-Diensten dafuer verwenden, aber
\r
155 dann Artet das ganze noch mehr aus und ich muss mich genau mit
\r
156 dem Zeugs auseinander setzen, dass mir immer wieder zeigt, wie
\r
157 schlecht die ganze Computer-Welt ist. Seufz. Aber eventuell
\r
158 wuerden die "normalen" Nutzer so etwas lieber nutzen? Vielleicht
\r
159 waere es ein Schritt, um der schleichenden "Proprietarisation of
\r
160 Communication" [3] entgegen zu wirken?
\r
162 > I'm talking about the messaging systems built into sites like
\r
163 > Facebook and LinkedIn. On several occasions recently, friends
\r
164 > have chosen to get back in touch with me via one of these rather
\r
165 > than by email. Another friend recently finished a conversation
\r
166 > with a third party by saying "Facebook me"; when I asked her
\r
167 > why she didn't just use email, she said "Oh, Facebook is so
\r
172 > But this is, nevertheless, a bad trend. It would be terrible
\r
173 > if email were to descend into something like the multiple
\r
174 > incompatible domains [Anmerkung: We have been there! Schonmal
\r
175 > was von AOL gehoert?] that afflict instant messaging - the
\r
176 > heroic efforts of gateway providers and multi-protocol clients
\r
177 > notwithstanding. Will we one day need accounts on every social
\r
178 > website in order to stay in touch? Will someone need to write
\r
179 > a Facebook/MySpace mail gateway?
\r
183 > Making real email easier to use is a first step.
\r
185 Mit diesem Schlusswort moechte ich mich fuer heute verabschieden,
\r
186 die Idee an sich ist nicht gestorben, aber es wird wohl am Ende
\r
187 zu ein paar XMPP-und-Atom-zu-Mail-Scripts hinauslaufen. Wobei ich
\r
188 mich bei einigen meiner Artikel schon ueber mehr Moeglichkeiten
\r
189 aus dem HTML5-Baukasten freuen wuerde... Seufz. Es bleibt also
\r
190 spannend. Nichts ist entschieden.
\r
193 [1] http://www.psyc.eu/
\r
194 [2] http://www.soup.io/
\r
195 [3] http://weblogs.mozillazine.org/gerv/archives/2007/06/the_proprietarisation_of_email.html
\r
projects / krt-msg / blob