Moderne Instant-Messaging-Protokolle, wie zum Beispiel Jabber, erlauben es bereits mit mehreren Clients gleichzeitig online zu sein. Auch das Problem der durch mehrere Rechner verteilten Nachrichtenhistorie kann mit Tools wie IMPULS, über das wir auch schon berichtet haben, gelöst werden.

Übrig bleibt das Problem, dass eingehende Nachrichten nur bei einem der angemeldeten Clients erscheinen. Bei Jabber ist das der Client mit der höchsten Priorität. Sitzt man gerade an einem der anderen Rechner, hat man Pech und wird über die Nachricht nicht informiert. Auch, wenn man den Rechner wechselt oder der Gesprächspartner an eine bestimmte Ressource schreibt, erfährt man von der Nachricht erst, wenn man genau den Zielclient öffnet.

Es fehlt ein System, bei dem man auf allen angemeldeten Clients jederzeit denselben Zustand vorfindet. Inklusive der aktuellen Nachrichten. Das entspräche auch der Vorstellung des Geprächspartners, der oft gar nicht weiß, welche Infrastruktur man selbst hat und welche Nachricht wo empfangen wird.

Der Begriff “Cloud Messaging” für dieses Konzept ist vom Cloud Computing abgeleitet, bei dem es ja auch darum geht, an jedem beliebigen Ort seine Daten und Applikationen vorfinden zu können. In diesem Fall geht es nicht allgemein um die Berechnung, sondern um Kommunikation, also eine Unterkategorie des Computings.

Es gibt eine einfache Lösung, die ich für ICQ schon lange anwende: Der Client (licq) läuft als Konsolen-Applikation in einer virtuellen Konsole mit screen. Über ssh kann ich mich mit meinem Server verbinden und dann auch auf mein ICQ zugreifen. Die Lösung erfüllt alle oben gemachten Forderungen. Sie hat aber drei Nachteile:

1. Ich brauche dafür einen Server, auf dem meine Software laufen kann.
2. Die Hardware, mit der ich zugreife, muss eine entsprechende Konsole darstellen können. Bei einem Handy wird das schon schwierig. Das Benutzerinterface lässt sich nicht an das jeweilige Gerät anpassen.
3. Da die Kopplung zwischen Applikation und Betriebssystem durch ssh und screen sehr lose ist, können spezielle Mechanismen des Zielgeräts – zum Beispiel das Abspielen eines Sounds bei eingehenden Nachrichten – nicht genutzt werden. Die Integration ist sehr schlecht.

Gerade offene Protokolle mit entsprechenden Client-Bibliotheken laden dazu ein, auf das jeweilige Gerät angepasste Applikationen zu schreiben. Deshalb muss das Cloud Messaging über das Protokoll realisiert werden.

Möglich ist zum Beispiel folgende Lösung: Der Server versendet nicht sofort die Nachrichten, sondern informiert alle Clients über die anstehende Nachricht. Falls sich Clients anmelden, wenn noch wartende Nachrichten vorhanden sind, werden diese ebenfalls informiert. Erst wenn ein Client die Nachricht wirklich angenommen hat, der Nutzer die Nachricht also aktiv auf dem Client empfangen hat, wird sie vom Server entfernt. Die übrigen Clients werden darüber informiert, dass die Nachricht empfangen wurde. Effektiv werden damit keine Nachrichten mehr verschickt, sondern Informationen über eine Änderung des Messaging-Zustandes des betroffenen Nutzers. Dieser liegt auf dem Server, wie das auch derzeit mit nicht abgerufenen Nachrichten der Fall ist.

Wenn dieses Konzept auf den Status erweitert wird, ist es außerdem möglich, transparent mit nur einem Gerät zu erscheinen, während man gleichzeitig mit dem Desktop-PC, dem Notebook und dem Handy online ist und die Wahl hat, auf welchem der Geräte man die Nachricht empfangen und die Antwort verfassen möchte.