Siehe auch: Jabber.

Auch witzig: http://html.pages.de/onXML/

Ist das noch aktuell mit psi und XMPP-XML?

Contents

[edit]

Gutes an Jabber

Raphael Wolfer hat einige feine Links zusammengetragen warum Jabber besser ist als proprietäre Systeme. Dieselben Argumente gelten auch für PSYC, da PSYC und Jabber (und IRC) fundamental sehr viel gemeinsam haben, anders ist nur dass PSYC erweiterbarer als Jabber ist, weil es nicht XML verwendet so wie es XMPP tut. Naja und überhaupt halt besser.  ;D

Warum Jabber und nicht Skype, ICQ, Aim, MSN, Yahoo, etc.?

[edit]

Anliegen

[edit]

Jabber kann nicht ircen

Jabber erfordert neue Clients. Es gibt haufenweise Chat- und Messagingclients. Die meisten Leute mögen ihre Clients. Warum sollten sie neue installieren? Mit PSYC können sie ihre IRC- oder Jabber-Clients beibehalten.

Einer der Autoren des HTTP-Standards, Larry Masinter von XeroxParc, beriet mich bei der Entwicklung des PSYC-Protokolls und erinnerte mich daran wie das Web seinerseits seinen Siegeszug antrat. Die Genialität des URL-Konzeptes allein hat die Welt nicht verändert, sondern dass der Browser tatsächlich bestehende Systeme wie GOPHER, FTP, WAIS, ja sogar Usenet News und E-Mail sowohl in die URL-Syntax als in die Software integrierte. Man musste also auf keinerlei bestehende Infrastruktur verzichten.

Jabber hat diesen Schritt für die Instant-Messaging-Systeme vollzogen. Bei dem Versuch IRC zu ersetzen ist es jedoch gescheitert, da es konzeptionell nicht auf Gruppennutzung und Multicasting ausgelegt ist.

PSYC wiederrum ist eine Technologie die von Anfang an -und nicht nachträglich- alle Fähigkeiten von IRC neu und korrigiert zu übernehmen vermag, und da Instant-Messaging ein Sonderfall von Multicasting ist, und nicht umgekehrt, kann es auch die Funktionen von Jabber konzeptionell integrieren inklusive aller Schnittstellen zu den existenten Instant-Messaging-Systemen.

(Gopher und Wais sind heutzutage irrelevant, aber damals waren sie die dominierenden Infosysteme im Zeitalter vor dem Web, und 1991 ahnten die wenigsten, dass WWW alles ändern würde.)
[edit]

Aufwand? Effizienz? Erweiterbarkeit?

Seit dem 30.1.2004 ist Jabber ein Standard der IETF und bekannt als XMPP. Der Kern umfasst 50 Seiten, die Instant-Messaging-Erweiterungen weitere 63 Seiten. Nimmt man die Verschlüsselungs-Dokumentation hinzu kommen nochmal zehn Seiten hinzu. Das IRC-RFC von '94 hat zwar auch knappe 60 Seiten, dennoch ist ein IRC-Client schnell und ohne großen Aufwand geschrieben. Zeilenweise übers Socket einlesen, ein bisschen Logik dazu und das wars. Das einzige Problem ist, dass die Nachrichten eine maximale Länge von 512 Bytes haben und die Struktur nicht sonderlich erweiterungsfähig ist. Zum chatten reichts.

Wie siehts bei Jabber aus? Man braucht einen XML-Parser, der Streams verarbeiten kann. Dann muss man aus dem ankommenden Zeichenstrom XML-Pakete basteln, dabei noch Namespaces etc beachten, bevor man endlich gucken kann, was denn überhaupt drin ist. Sprich ein Heidenaufwand. XML ist ja schön und gut wenn man erweiterbare und austauschbare Sachen machen will zwischen heterogenen Systemen die nicht auf Kooperation ausgelegt sind. Aber ist ein XML-Protokoll da nicht ein Widerspruch in sich? Wenn beide Seiten das gleiche Protokoll sprechen, wozu ist XML da nötig? Mehr dazu auf http://html.pages.de/onXML/

Die Jabber-Erweiterung Multi-User Chat besitzt einen Abschnitt 'IRC Command Mapping', der zeigt, wie man IRC-shortcut-Kommandos zu kompletten XML-Paketen erweitert. Wo ist der Mehrwert gegenüber den IRC-Kommandos, die übertragene Information bleibt gleich.

Wo steht PSYC im Vergleich? Wir behaupten, gleichzeitig erweiterungsfähig und einfach zu parsen zu sein. Erweiterungsfähigkeit bedeutet, dass wir keine positionale Syntax wie IRC haben. Einfach zu parsen heisst, dass wir eine RFC-822-ähnliche Notation für Variablen und ihre Werte benutzen. Effizient heisst, dass wir eine Chatsession mit möglichst wenig Bytes über die Leitung transportieren wollen.

[edit]

Fragen & Antworten

[edit]

Wie ist das mit IMPP und XMPP? Ist es nicht ein Rückschritt für PSYC zu diesen RFCs compliant zu sein?

IMPP kann kein Multicast, also kann es nicht sinnvoll eine Nachricht an mehrere Leute herausverteilen, wobei Multicast jetzt als Konzept gemeint ist, die technische Umsetzung sollte auswählbar sein und hat derzeit in unserem Falle nichts mit "IP Multicast" zu tun. Wir erfüllen die Ziele von IMPP, auch wenn wir mit dem Multicasting eigentlich höhere Ansprüche stellen. XMPP speziell verwenden wir ja nur im Umgang mit Jabber-Servern. Das Jabber- Protokoll kann man ja nicht zu Multicasting aufrüsten ohne zugleich RFC-brüchig zu werden, da XMPP solch eine Änderung nicht zulässt. Wir haben die Jabber-Entwickler und das IETF oft genug auf dieses Problem aufmerksam gemacht, aber die wollten nur schnell ein RFC durchkriegen und keine Diskussion führen über effiziente Verteilung der Anwesenheitsdaten.

[edit]

What about a PSYC transport?

"Dir" ist im nachfolgenden lynX.

MarkusBrechtel sagt Dir
man könnte die jabberintegration von psyc verbessern. ich habe eine idee. die idee ist den zugang zu psyc wie einen jabbertransport zu machen, dadurch könnte man das psycnetzwerk über einen jabberaccount benutzen
Du fragst MarkusBrechtel
hm, du kannst doch mit jedem psyc-user über jabber reden.. was soll der transport da noch beitragen?
MarkusBrechtel sagt Dir
ja, das hab ich mir ja auch schon gedacht. so kann man mit einem jabberaccount eine richtige psycadresse benutzen
Du sagst MarkusBrechtel
ich versuch mir das auszumalen.. aber als jabber-user ist man ja in psyc nicht ausgeschlossen.. xmpp:user@host ist ja in psyc auch eine gültige adresse.. psyc ist ja offen für andere schemes
MarkusBrechtel sagt Dir
ja, ist nicht wirklich notwendig, das weiß ich, aber es wäre eine schöne sache,finde ich
Du sagst MarkusBrechtel
kurios.. also ich hatte mir schon überlegt psyc-befehle zu erlauben für jabber-user .. besser gesagt, es gibt bereits mehrere /-befehle die man in jedem psyc "muc" ausführen kann, und das könnte weitergehen, dass der psyc server einstellungen für deine jid speichert, etwa deine psyc-farbe.. nen transport zu machen wäre gleich nen schritt weiter.. aber eben auch nicht mehr ad hoc spontan. ... okay.. also die sache rechnet sich sobald man einen topologisch nahen transport hat.. dann sind psyc multicasts effizienter als das xmpp-muc protokoll.. sofern der transport überhaupt sowas komplexes wie multicasts an dich weiterleiten kann.. und genau deshalb ist es dann doch käse, weil es einfach einfacher ist einen eigenen user auf einem psyc server anzulegen über die jabber client schnittstelle.. das ist für jabber clients einfach ein weiterer account - letztlich sauberer als ein transport... also der beste weg nen psyc account von jabber aus zu haben ist einen psyc account von jabber aus zu haben  ;) ein transport wäre nur für personen interessant die par tout einen single-identity jabber client verwenden wollen.. oder habe ich was übersehen?

fippo versteht den Sinn und Zweck dieser Sache nicht. Wir können (in der Theorie, die Implementierung ist ein wenig eingerostet) sehr gut auch als Server für Jabberclients agieren, was den separaten Jabber-Account dann überflüssig macht. Einziger Nachteil ist dann, dass man nicht in remote mucs joinen kann. Aber ich hab immer noch keinen gesehen, der es wert wäre. Wenn dem Herrn Brechtel die Features unsere Jabberclientzugangs nicht ausreichen kann er mich gerne nach Semesteranfang auf eine Tasse Kaffee in die Mensa einladen und mir das erläutern, ich hab sowieso vor, da noch einiges an Arbeit reinzustecken.

fippo: ah... dem Herren fehlten die Transports. Aber daran arbeiten wir ja gerade.