IBM recommends XMPP for Realtime Web Apps

There is a new tutorial from IBM about how to build modern realtime web apps. In the tutorial IBM suggests using XMPP, BOSH from JavaScript. It is worth reading.

http://www.ibm.com/developerworks/xml/tutorials/x-realtimeXMPPtut/index.html

This is exactly how weblin.lite was built 2 years. Even including the HTTP proxy to circumvent the JavaScript security limitation, tunneling XMPP through HTTP with BOSH, using a real XMPP server for message routing and a JavaScript XMPP client library to communicate. Also: jQuery, Ajaj, XML, JSON, WebServices, mysql. Basically, all the cool web-tech stuff we like.

Congrats to the weblin dev team. The best dev team I've ever had.

_happy_boshing()

Yes, we have been there. Now it is so much a standard, that IBM recommends the technology. It will be picked up by many others and we are already the experts. So much for certain ignorant investors and business angels, who do not recognize technology in their portfolio, even if it jumps into their face. We will be there without you.

Integration Tests are a Superset of Unit Tests

The agile world is unit test crazy. That's ok. But it is not enough. Integration tests are a much under valued species. I like unit tests. I need unit tests. I do not know how we could ever build software without unit tests. But pure unit tests jump too short. We need more.

I am talking about unit test frameworks like NUnit. You just write the test function, add an attribute and the framework finds the function and adds it to the test list. Your test function tests a real function. Hundereds of those make a complete test set. Great, but not enough. What is missing?

You are supposed to write unit test code, which tests only single functions and methods. The idea is to isolate functionality and test isolated. I know the theory: Interfaces are contracts. There are unit tests for every behaviour. Even failures should be verified. TDD (test driven develpment) write the test as specification. I know all that bloat.

Fact is: these tests are important, but they ignore reality. Most problems result from interdependencies and side effects. In theory, there are no side effects. In reality they are there. Unit testing reduces them. Unit testing gives complex systems a chance to work. Chance is not enough. We must make sure, that systems work, not only functions. That's the part of the integration test.

Integration tests verify complex operations. Example: assumed I have a typical cached business object. An integration test would check the complete process:

• fetch the object from the cache,
• if it's not there, construct it from the DB,
• put it in the cache and
• return it at the same time.
• communication with the DB includes a
• web service interface and 2 layers of
• storage driver and
• SQL access code.

This is a vertical test.

In contrast: unit tests would test everything isolated:

• does the cache access work? with a simulated in-memory cache. Beware of the network inside of unit tests.
• does the database access work? using a fake DB, because relying on a real DB server is uncool, not "isolated" enough
  
• would the webservice return the correct data? using a mock request object and fake data.
• does the webservice format correctly? again: fake data
  
• everything tested with made up configuration data and carefully constructed dependency injection.
  

I am totally pro isolated tests. But they are so un-real, mocked-up, simulated. They need something real on top. They need integration tests. Integration tests assert, that complex systems work despite complexity. We need integration tests. Wenn need lots of them. Unit tests just hope, that everything works together. Dream nicely.

We need integration tests anyway. And integration tests are in the real system. They are live. Unit tests are in a separate project and can not be live. Two separate test sets. Too many for me. There is no reason to split testing into 2 test sets, which are operated very differently. You run the test project from time to time and you are happy about the green bar. I run the real project all the time. Why should I run the test project from time to time, when I can run tests in the real environment with just one click.

Integration tests can be written to test isolated functions. They are a superset of unit tests. My interation tests check isolated functions PLUS vertical functionality PLUS live system health.

Unit test frameworks jump too short. They help, but ignore reality.
Get real. Switch to integration testing.

Update:

Changed the title from "Superior to" to "a Superset of".

_happy_testing()

HTML Video Tag

They did it again. 15 years after the img-tag, they invented a video-tag. I know, that native video makes the world better. I am totally pro-video. But to call the tag "video" is just plain wrong.

In HTTP, the server tells the content type of data. The client has no say. But if you call a tag "img" (or "video") then the browser expects a certain (subset) of content types. Ever tried to return an HTML from the URL of an img-tag: broken image. Even though it was valid HTML. Why doesn't the browser show an embedded HTML fragment instead? Why does it insist on an image? The browser requests a resource by URL to fill some screen space. If the server returns HTML, the client could show the HTML. This would have eliminated the need for frame and iframe.

One embed-tag would have been enough instead of img, iframe, and video. An embed-tag would simply tell: "here comes some screen space that is to be filled with the src-URL". And nobody would care if the content type is an image or PDF or video or HTML.

On the other hand, it's not really that bad.
Not really worth a rant.
Thanks for the native video, guys.
It's cool.
Especially combined with (the much too long ignored) SVG.

:-) It's not like embedded native video hasn't been postulated 13 years ago. I asked them at RTMW 96 (last century), if they would just add a video codec to the browser and a simple request/response. But back then, people wanted to make it complicated with RTSP, multimedia frameworks and such. In the meantime we had never-really-working-MPEG-plugins, a Microsoft video player disaster, a Flash workaround, because Macromedia just could not stand it anymore. Finally, the browser guys made it as simple as requested in 1996.

_happy_embedding()

Listen to Engineering

This is a corporate culture I like:

"Palantir runs a tight ship, providing vital information on an internal wiki, keeping meetings concise and striving to hire candidates with “an engineering mindset, even in our administrative people,” McGrew says.

The division of the company devoted to government products has only one ten-minute meeting every week to make sure developers and managers are on the same page and to discuss prospective customers. There is also a company policy against using PowerPoint decks.

The company is also unique in that it doesn’t have any soft-skills marketing or sales personnel. All customer-facing employees have degrees in computer science or symbolic systems and are capable of walking customers through software installations and debugging. This has helped Palantir build tighter relationships with its clients."

We are in a technology business. Technology is king. Engineering knows what to do. Of course many other people also know and we need their input. But if engineering fails to know, then the company is doomed anyway. No technology agnostic, smart ass business developer, investor relations, sales driven product management can save it then. It's the technology, stupid. Get over it.

To hell with your "how to manage companies the old way" books. To hell with "IT is a service department". To hell with your "great managers who sell bad decisions for good, because they once though they were good and can not admit that they turned out bad".

This is technology and you listen to us!

You don't believe me, because I am just a techie? Maybe you believe IMVU or Toyota: http://startuplessonslearned.blogspot.com/2008/11/sciencedaily-corporate-culture-is-most.html

happy_listening()

Windows Unicode

Der Windows Kernel ist komplett Unicode, und zwar immer 2 Byte, nämlich "unsigned short". Das hat die Portierung von ASCII zu Unicode und paralleles Programmieren von ASCII und Unicode Programmen erleichtert. Man programmiert alles in C++ Macros mit TCHAR als Datentyp und der Compiler macht entweder ASCII (char) oder Unicode (WCHAR).

Soweit so gut. Aber wenn man plattformübergreifend programmieren will, also das gleiche auch auf Mac/Linux kompiliert, kann man TCHAR nicht verwenden. Auf Unix gibt es nur UTF-8. Viele Open Source Libraries sind auch nur in UTF-8, manche in ASCII, aber fast keine in Windows Unicode.

Ich sage: WCHAR war ein Fehler. Sie hätten den Kernel in UTF-8 machen sollen. WCHAR ist nicht wesentlich schneller als UTF-8, ausser, wenn man in langen Texten einen Buchstaben sucht, aber wann macht man das schon und wenn kann man es auch bei UTF-8 effizient hinbekommen. Es ist auch nicht wirklich richtig einfach zwischen ASCII und Unicode umzuschalten. Die "Einfachheit" von TCHAR erkauft man durch viele C++ Macros, viel Disziplin beim Programmieren und doppeltes Testing.

Ich programmiere jedenfalls auch auf Windows in UTF-8. Die Stringklase macht UTF-8. Wenn man das WinAPI bedient, dann wird in Windows Unicode gewandelt. Erstaunlicherweise hält mich jeder gestandene Windows Programierer für verrückt, manche sogar für unfähig, unerfahren, nixblickend. Alle meinen es echt gut und wollen mir erklären, wie man auf Windows "richtig" programmiert: WCHAR für interne Verarbeitung und UTF-8 für Datenaustausch, ich weiss. Ständig konvertieren soll toll sein? Warum nicht immer UTF-8 und nie konvertieren, dabei auch noch mit anderen Plattformen und Libraries kompatibel sein?

Ein deutliches Indiz dass was faul ist, ist dass der NT Kernel ursprünglich auf genau 2 Byte pro Buchstabe festgelegt war. Das nennt sich dann UCS-2. Später hat man das umdefiniert zu UTF-16, was soviel heisst wie: ein Buchstabe hat 2 oder 4 Byte. Damit entfällt die feste Länge und praktisch der gesamte TCHAR Mechansimus ist ad absurdum geführt. UTF-16 ist für UCS-2 genau das gleiche wir UTF-8 für ASCII. Wenn man von UCS-2 auf UTF-16 wechselt, dann hätte man auch gleich von ASCII auf UTF-8 wechseln können ohne den unglaublich aufwendigen Umweg über WCHAR.

Ich weiss was alle denken, was richtig wäre auf Windows, aber ich glaube trotzdem dass da jemand anders mal einen dicken Denkfehler gemacht hat und alle Windows Programierer machen seit 15 Jahren mit.

_happy_coding()

Solarenergie aus dem Weltraum

Das Thema geht ja immer mal wieder durch die Presse: man macht kilometergroße Solarsatelliten und strahlt die Energie per Mikrowelle zur Erde. Ist teuer wegen den Startkosten, aber es gibt immer wieder Vorschläge, die behaupten es ist finanzierbar. Und wenn dann alle Energieprobleme gelöst sind, kann man es sich ja auch was kosten lassen.

Kann ja sein, aber irgendwas ist daran komisch.

Der Punkt ist: die Solarsatelliten erzeugen Strom, der zur Erde tranportiert werden muß. Kabel geht nicht. Aber Mikrowellen kann man einfach erzeugen und ziemlich effizient wieder einfangen mit sogenannten Rectennas.

Nun haben aber manche Leute Angst, dass der Mikrowellenstrahl "abhauen" könnte und Leute in Städten röstet oder dass Vögel durchfliegen und gebraten werden. Vom Waffenpotential mal ganz zu schweigen. Deshalb fächert man den Mikrowellenstrahl so weit auf, dass er keinen Schaden (respektive Kriegsnutzen) anrichten kann. Er hat dann etwa die Energiedichte von normaler Sonnenstrahlung. Das ist dann für alle verständlich, weil Vögel ja sonst auch kein Problem mit der Sonne haben.

Für 1 Gigawatt, das entspricht etwa einem Kernreaktor, braucht man ein 1 km großes Feld von Empfangsantennen. Kann man machen, ist sicher nicht billig. Aber was mich vor allem wundert: warum fängt man nicht gleich Sonnenstrahlung auf dem Boden ein, statt Sonnenstrahlung im Weltraum, dann per Mikrowelle zur Erde und auf dem Boden Mikrowelle einfangen. Wenn die Leistungsdichte des 1 km breiten Mikrowellenstrahls so ist, wie die Sonnenstrahlung dann kann man doch gleich die Sonnenstrahlung einfangen. Die Sonne liefert ca. 1 kW/qm. Das nennt man Solarkonstante. Genauer: 1,37 kW +/- 5% pro Quadratmeter. Aber 1 kW reicht als Abschätzung.

Und siehe da, 1 kW/qm multipliziert mit 1 Quadratkilometer Empfangsfläche ist genau 1 Gigawatt. Natürlich hat man Nacht und mal Wolken, aber statt das Zeug ins All zu transportieren kann man auch einfach 4 mal so viele Solarkollektoren bauen. Für den Preis des Transports bekommt man sicher 4 mal so viele Solarzellen oder Spiegel. Kommt noch dazu, dass man auf der Erde nur auf Energieeffizienz achten muß, im Weltraum aber vor allem auf Gewicht. Da meistens leichter=teurer kann man sich auch deswegen mehr Quadratkilometer auf der Erde leisten.

Dass mir jetzt keiner sagt man muß Platz sparen. Platz ist genug da. Und zwar genau dort wo er billig ist und die Sonne ohne Wolken brennt: in der Wüste. Auch die Mikrowellenempfänger würde man ja wohl in der Wüste bauen. Jedenfalls abseits von Städten und da wo keiner jammert, wenn das Gemüse mal ausversehen Mikrowelle abbekommt, d.h. nicht in der Kulturlandschaft. Berge sind auch unpraktisch.

Bei so attraktiven Kriterien wie "flach, billig, leer, trocken" bleibt auf der Erde nur die Wüste. Es gibt Millionen Quadratkilometer Wüste. Nevada reicht für die USA. Ein tausendstel Sahara reicht für allen Strom in Europa. Kurze Rechnung: 1 Atomkraftwerk bringt pro Reaktor ca. 1 Gigawatt. Die Sonne pro Quadratkilometer auch. Die Sahara hat 9 Mio. Quadratkilometer. Das wären 3 Mio. Atomkraftwerke. Baut man nur ein Hundertstel der Sahara mit Solarzellen oder Spiegeln zu, dann erzeugt man genügend Strom für die ganze Erde. Auch in Zukunft. Energie ist nicht knapp. Die Sonne liefert im Überfluß. Wie nutzen sie nur nicht.

Zurück zu Solarenergie aus dem Weltraum: also entweder

• der Mikrowellenstrahl wird doch gebündelt und hier ist eine große Augenwischerei im Spiel

oder

• Solarsatelliten mit Mikrowellenübertragung sind totaler Unsinn und man sollte lieber 4 Quadratkilometer Solarzellen in die Wüste bauen, statt 1 Quadratkilometer voller Mikrowellenempfänger.

oder

• ich habe was nicht verstanden.
  

Mal ganz davon angesehen, dass man sowieso nicht Tausende Quadratkilometer Solarzellen herstellen würde, sondern eher solarthermische Kraftwerke, die Sonnenstrahlung mit Spiegeln bündeln.

_happy_burning()

Der erste schwarze Präsident - hä?

Schon mal jemand aufgefallen, dass eine weisse Mutter und ein schwarzer Vater zusammen etwa fifty-fifty ergibt. Das kann man auf- oder abrunden (wenn man unbedingt runden muss). Oder zählt das weiss weniger, weil von der Mutter? Ist das versteckter männlicher Chauvinismus? Und wieso sind die "Weissen" (wer auch immer die sind, klingt irgendwie wie billige Nahrungsmittel) so scharf darauf, möglichst wenig zu sein? Jedes Baby, das mal einen pigmentierten Uropa hatte, wird den "Schwarzen" zugerechnet. Vorsichtshalber werden auch alle mit spanischen Omas rausgerechnet. Schon klar, dass die "Weissen" in USA Angst haben müssen "die Mehrheit zu verlieren". Wie blöd muss man eigentlich sein?

Viel Glück Me.dium

http://denver.bizjournals.com/denver/stories/2008/07/21/story9.html

Me.dium macht jetzt Google Konkurrenz:

"What we show you is what people are interested in and find useful". Wenn sich das nicht nach Google anhört.

"We don’t think we’re going to take Google out", na dann.

Früher hat Me.dium die Leute angezeigt, die auf "verwandten" Webseiten gesurft sind. Also nicht nur auf der gleichen Domain, wie weblin, RocketOn, Skabble, sondern auch Seiten mit ähnlichem Content. Ich gebe zu, dass mir das schon immer zu komplex war. Content crawlen und den Inhalt herausfinden, dann Inhalte assoziieren ist eine schwierige Sache. Das ist ziemlich genau das was Suchmaschinen machen und sicher nicht das was eine kleine Firma gut kann. Wenn man wie Me.dium jetzt das Surfverhalten seiner User dazu nimmt, kann das sicher helfen. Aber wer glaubt denn, das Google das nicht macht? Google bekommt über ziemlich viele GAnalytics Tags das Surfverhalten und wer auf Suchergebnissen klickt sagt Google auch was gut ist. Das Surfverhalten dass Me.dium bekommt ist im Vergleich dazu vielleicht etwas besser und vollständiger, aber vermutlich nicht so viel besser, dass man die Suche ernsthaft besser machen kann als Google.

Me.dium bekommt etwa die Daten, die auch Alexa hat. Alexa hat auch ein Search Produkt, Alexa: "Alexa has taken search and browse to the next level and made it more complete, more relevant and more useful." Natürlich verwendet Alexa die Daten, die die User "nur zu rein statistischen Zwecken" schicken auch für die Suche. Und hat man schon mal von Alexa Suche gehört? Kann ja sein dass sie Google aussticht, aber so bekannt ist sie nicht obwohl Alexa schon seit 10 Jahren auf dem Markt ist. Alexa gehört zum Web-Urgestein.

Warum glaubt Me.dium Alexa und Google Konkurrenz machen zu müssen. Der Search-Markt ist sowieso gesättigt (oder zumindest eng). Microsoft versucht sich da seit Jahren mit viel Geld. Ich glaube Me.dium sollte lieber in Konkurrenz zu weblin, RocketOn, Skabble, usw. bleiben und sich um 100 Mio. neue User auf einem noch nicht gesättigten Virtuel Presence Markt schlagen.

Mal von Marktchancen abgesehen, finde ich es immer noch bedenklich, dass Firmen das Surfverhalten der User verfolgen und alle URLs mitlesen. Das macht Alexa schon immer so, Me.dium jetzt auch, Google "nur" auf den eigenen Seiten und da wo Web-Admins ein Analytics-Tag einbinden, Facebook hat sich mit Beacon, gerade eine leichtrote Nase geholt. PMOG, RocketOn, Skabble natürlich auch.

Aber ich bleibe dabei: Web-URLs von Usern sollten den PC nicht verlassen. Zumindest nicht für den Basisdienst. Wenn User/in will, dass das Surfverhalten FÜR IHN/SIE verwendet wird, dann ist das was anderes, aber Web-Dienste, die nur auf dem Übertragen von URLs basieren, bereiten mir Unbehagen. Das muss auch anders gehen. Man kann doch nicht Leuten eine Toolbar unterschieben nur damit man an alle URLs kommt, die sie absurfen.

Naja, trotzdem viel Glück Me.dium

Nachtrag: Anscheinend ist das auch noch anderen aufgefallen. Hier ein Vergleich Google, Cuil, Me.dium bei dem Me.dium sogar deutlich vorne liegt.

RSS-Feeds: eine Fehlentwicklung - warum XMPP besser gewesen wäre

Ich bin ja wirklich ein Fan von RSS-Feed-Readern. Inzwischen besuche ich gar keine Blogs mehr, sondern lese nur noch die Feeds im Reader. Echt toll, dass die Nachrichten zu mir kommen, statt dass ich alle Websites abklappern muss.

Schade nur...

...dass die Nachrichten gar nicht zu mir kommen, sondern dass meine Software sie abholen muss. Ich muss zwar nicht alle Websites abklappern, aber mein RSS-Client schon. Der schaut ständig nach ob es was neues gibt (polling). Dabei sollt er eigentlich benachrichtigt werden. Der Begriff RSS-Feed ist glatt gelogen. RSS-Feeds sollten RSS-Fetch heißen. Nochmal: Die Nachrichtenquelle sollte eine Nachricht an meinen Reader schicken, statt dass mein Reader alle 10 Minuten nachschaut ob etwas neues da ist. Traffoc-mässig echt eine Schweinerei und nur im Zeitalter von Torrent und Videodownloads gerade noch tragbar.

Diese Fehlentwicklung liegt natürlich daran, dass der ganze RSS-Mechanismus auf Web-Technologien aufbaut, die wegen HTTP per se nur Request-Response können. Dabei gibt es etablierte Technologien mit denen man einen echten News-Feed aufbauen könnte, z.B. XMPP/Jabber.

Was besser gewesen wäre

Bei XMPP ist mein Client ständig mit meinem Server verbunden. Andere Server können jederzeit zu meinem Server Kontakt aufnehmen und dieser schickt dann alles an mich weiter. Wenn ich einen News-Feed haben will, dann registriere ich mich mit meiner Adresse bei der Nachrichtenquelle. Die Nachrichtenquelle schickt mir dann immer eine Mitteilung, dass etwas neues da ist (mit Titel und Zusammenfassung). Mein Reader zeigt es mir sofort (!) an und ich kann die Nachricht lesen. Kein "Pollen", keine Verzögerung, kein unnötiger Traffic.

Jetzt mal ehrlich...

...RSS ist Really Stupid Syndication. Diese Art von News-Pollen gehört in den Mülleimer der Geschichte. Die Zeit ist reif für ein Message-basiertes News-System. Die Technik ist verfügbar: XMPP und andere IM.

Aber inzwischen gibt es so viel Content der die schlechte alte Technik benutzt, dass wir noch lange damit leben werden müssen. Und mit Web-basierten RSS-Readern entspannt sich auch die Lage beim Traffic, weil ein Betreiber (z.B. Google) die Feeds für alle gemeinsam abfragt. Und wenn es komplizierter gewesen wäre, dann hätte es sich vielleicht nicht so durchgesetzt und es wäre weniger Content verfügbar.

Lesen Sie auch bald wieder hier: "Web und Request-Response: eine Fehlentwicklung - warum ein Mesh und Messaging besser gewesen wäre".

IM Protokolle: eine Fehlentwicklung - warum SMTP besser gewesen wäre

Ich bin ja wirklich ein Freund von XMPP als Instant Message Protokoll. Und ich finde auch IM als Dienst mit all seinen Anwendung von Status Updates, über Chat bis Unified Messaging ganz toll.

Aber: dafür hätte man keine neuen Protokolle gebraucht. SMTP mit ein paar kleinen Erweiterungen hätte völlig ausgereicht. Messaging ist ja sozusagen die Kernkompetenz von SMTP. Dafür wäre sicher kein neues Protokoll nötig gewesen. Was sind Status Updates anderes als Messages? Chat: Messages mit einer Thread-ID. SMTP kann beliebige Content-types: text, HTML usw. Das hat HTTP schließlich von SMTP gelernt. Wie wir alle wissen kann SMTP sogar multipart messages (MIME). Das muss ein IM Protokoll erst mühsam nachmachen.

Um hier mal mit Mythen und Halbwahrheiten aufzuräumen:

IM ist schneller als Email

EMail ist nur deshalb langsam weil mein Email-Reader nur alle 5 Minuten die Email abholt. Würde er seine TCP Verbindung zum Mailserver stehen lassen, dann könnte der Server immer sofort die Email an den Client weiterleiten. Sozusagen COMET für SMTP. Wenn es bei HTTP geht, dem Prototyp eines Request/Response-Protokolls, dann geht es auch bei SMTP. Noch besser: jeder sollte einen SMTP Server im Email-Client haben und der Company-Server forwarded einfach live an den Client. SMTP Messages gehen meistens 3 Hops: Sender -> lokaler Server -> entfernter Server -> Empfänger. Das ist genau die gleiche Topologie wie bei XMPP.

IM ist SPAM-resistenter als Email

Nur manche IM Systeme sind SPAM-resistenter und zwar deshalb, weil das Gesamtsystem in einer Hand ist. z.B. können bei zentraler Registrierung Accounts gebannt werden. Oder weil sie Dialback und Sender-Authentifizierung machen. Das ist aber nicht das Protokoll, sondern das Gesamtsystem. Ein Emailsystem mit Sender-Auth, Dialback und Benutzern, die nicht alles glauben ist genauso gut oder schlecht SPAM-resistent wie IM.

Mit SMTP kann man nur Emails verschicken

SMTP kapselt alles was man will. Alle MIME-Typen (MIME! klingelts?), vor allem auch XML. Auf XML sind ja ein paar IM Protokolle mächtig stolz. Mit beliebigem XML in SMTP lassen sich auch beliebige Daten übertragen. Es gibt sogar einen SMTP Network-Layer in .NET zum Transport von SOAP-XML als Remote Procedure Call. Natürlich hätte man auch ein bisschen Status-XML übertragen können. Oder Subscriptions, Notifications, Requests, Responses, und alles was man sich nur wünschen kann.

Warum SMTP besser ist (gewesen wäre)

SMTP ist hochentwickelt im Vergleich zu IM Protokollen. Und das sogar immer noch obwohl IM nun schon über 10 Jahre alt ist.

SMTP ist einheitlich während die IM-Welt zersplittert ist.

SMTP hat Offline Storage eingebaut. Manche IM Protokolle mussten das erst wieder erfinden.

Die SMTP Infrastruktur war schon weltweit operativ, robust und verstanden. Es wäre nicht notwendig gewesen neue Software zu machen, zu betreiben, kennen zu lernen.

Meine IMs würden automatisch archiviert, wie Emails. Es gäbe da keinen Unterschied. GMail hat das gerade wieder erfunden.

Es gibt Web-basierte Email-Reader, sehr praktisch im Urlaub. Auch das haben die IMs wieder erfunden (z.B. Meebo), aber warum ist das überhaupt separat. Ach ja, GMail hat GTalk mit eingebaut. Schade, dass sie überhaupt was einbauen mussten.

Was notwendig gewesen wäre

Um SMTP noch ein bisschen leichter zu machen hätte man z.B. SMTP Pipelining verwenden können. Pipelining befreit SMTP von den 4 Round-Trips. Nicht dass es wirklich wichtig wäre.

Eine Art SMTP-COMET oder einfach ein SMTP-Server für Jedermann.

Jetzt mal ehrlich...

...meine Kommunikationsanwendung ist Thunderbird oder Outlook. Die Buddyliste gehört in Thunderbird. Sie sollte identisch mit dem Adressbuch sein. Ein Adressbuch mit Online-Status. Und kurze Email heißen dann IM.

Trotzdem gibt es XMPP und andere IM Protokolle. Und dabei wird es auch bleiben. Lesen Sie auch bald wieder hier: "RSS-Feeds: eine Fehlentwicklung - warum XMPP besser gewesen wäre".