Stefan
@stefan@devlug.de
Wenn da jemand Erfahrungen hat, sag doch mal Bescheid.
@stefan Hmmm... ich weiß nicht allzuviel über diese Sachen. Vielleicht liege ich falsch (und bitte korrigiere mich wenn ich falsch liege), aber die library beeinflusst ja nicht die Bedienoberfläche, oder? Ich stelle es mir jedoch schon cool vor, über das Terminal zu chatten, doch ob es Blinden wirklich hilft, kann ich mir schwer vorstellen. Lass mich gerne wissen, wenn du diesbezüglich ein Projekt startest. Ich verfolge sowas immer gerne :)
Um die verschiedenen Funktionen etc der library zu testen und auch das API Design zu validieren, braucht man auch ein Client.
Ich habe an etwas wie ein virtuelles Filesystem gedacht.
talksh> loginVielleicht werde ich es so oder so mal anfangen, weil ich die Idee total lustig finde. Wenn es jedoch wirklich jemand gebrauchen / helfen kann, ist ja noch besser.
< JID: ich@domain.tld
< Passwort: xxxxxxx
Connecting...
Connected.
talksh> ls /online/
Otto
Willi
talksh> ls /offline
Anna
talksh> chat /buddy/Otto "Wollen wir morgen Rad fahren?"
libstrophe macht "XMPP". Also, RFC 6120 XMPP Core, RFC 6121 XMPP IM, RFC 7622 XMPP Address Format.
Man sollte libstrophe als eine "low-level" library sehen. Wenn man z.b. #IoT machen will, dann braucht man vielleicht nur einen ganz, ganz kleinen Teil von Erweiterungen.
Die Erweiterungen werden als XEP bezeichnet. Diese wiederum hängen etwas stärker an dem konkreteren Anwendungsfall. Will man z.b. ein "modernes" messenger system haben, kommt man um eine lokale DB für die Nachrichten nicht drumherum. Auch die ganze E2EE (OpenPGP / OMEMO) sind viel Client seitige Implementierungen und habe in einer low-level lib nichts verloren.
Deswegen ist die Idee eine "IM Client XMPP" lib auf libstrophe drauf zu setzen.
History