Yet Another Firefox Chat on Webpage Plugin

Sie kommen. Erst yakalike, dann Search Party, jetzt QuickChat und NetMite Communities
Vier relativ neue Firefox Plugins mit denen man auf Webseiten einen Chatkanal öffnen kann, um mit den Leuten zu chatten, die zur gleichen Zeit auf der gleichen Seiten sind. Das naechste heisst dann YAFCWP: Yet Another Firefox Chat on Webpage Plugin.

Das bedeutet aber auch
1. dass die Leute es endlich gefressen haben, dass man auf dem Web andere treffen will
2. dass LLuna jetzt noch eins darufsetzen muss, um den Vorsprung zu halten.

Bisher haben sie noch nicht verstanden, dass ein Chat-Channel alt ist, Avatare und Sprechblasen besser sind. Wenn sie das merken, wird es eng. Bis dahin sollten die LLuna Avatare animierte 3D Figuren sein.

_happy_coding()

Peer to Peer Sockets: die Wiedergeburt des Internets

Vor 2 Monaten hat Google LibJingle veröffentlicht. Enthalten ist darin ein sogenannter Peer to Peer Socket (p2p). Der p2p Socket überträgt Daten zwischen 2 Computern. Das ist eigentlich nichts spektakuläres. Der Unterschied zu normalen Sockets ist, dass sich der p2p Socket einen möglichen Weg sucht und dabei auch Relays benutzt und asymmetrische Kommunikation. p2p Socket "Verbindungen" gehen im Gegensatz zu einfachem TCP/UDP über Firewalls. Der p2p Socket ist eine Abstraktionsschicht höher, als UDP/TCP Sockets. Er testet, wie Computer an das Internet angebunden sind und wählt dann selbst die beste (oder einzige) funktionierende Verbindungsmethode aus. Falls alle Stricke reißen verbindet er zu einem Relay über den TCP Port 443 und tut so, als ob er ein Webbrowser ist, der SSL macht.

Die gesamte Komplexität einschließlich der Relay Server im Internet ist in einer Library verborgen. Die Technik ist nicht neu. Sie wird seit Jahren in p2p Filesharing Netzen und bei Skype verwendet. Aber mit LibJingle steht so eine Funktionalität jetzt als Open Source (BSD Lizenz) zur Verfügung. Jeder kann p2p verwenden ohne den aufwendigen p2p-Teil programmieren zu müssen. Man kann p2p Funktionen in eigene Anwendungen einbauen und endlich wieder kommunizieren. Das klingt banal, ist aber eine Revolution.

In der Anfangszeit des Internet konnte man einfach Programme schreiben, die per TCP Daten von einem Computer zum anderen übertragen haben. Jeder konnte zu jedem verbinden, per TCP und UDP. Dann kamen Firewalls und NAT und haben die Computer voneinander isoliert. Heute können Arbeitsplatz- und Home-PCs nur noch mit Servern kommunizieren, aber nicht mehr direkt miteinander. Computer wurden zu Clients degradiert. Es ist schwierig einen Server zu betreiben, weil die meisten Computer hinter Firewalls, NAT und dynamisch vergebenen IP Adressen versteckt sind.

Mit öffentlich verfügbarer p2p Technologie können Computer wieder miteinander kommunizieren. Das Internet wird wieder geboren als das p2p Netzwerk, dass es früher einmal war.

Beispiel VoIP: IP-Telefonie braucht SIP Gateways und/oder Firewall-Regeln für SIP-Datenpakete. Das funktioniert nur zwischen Firmen, die sich für SIP entschieden haben, SIP Produkte gekauft haben und betreiben. Das kostet Geld und geht nicht überall. MS Netmeeting ist daran gescheitert. Mit Skypes p2p Technik wurde IP-Telefonie wieder möglich. Mit Googles Library kann man jetzt IP-Telefonie in alle Programme einbauen.

Beispiel Filetransfer: Filetransfer in Instant Message (IM) Systemen geht, wenn die IM Server den Filetransfer-Traffic aushalten. Das funktioniert gut bei den großen IM-Netzwerken, aber ein offenes und verteiltes IM-System (Jabber/XMPP) hat Schwierigkeiten, weil sich die Server untereinander den Filetransfer-Traffic weiterleiten. Viele Jabber Server werden von kleinen Organisationen betrieben und wollen nicht unkontrollierten Filesharing-Traffic. Deshalb ist Filesharing-Support nicht allgegenwärtig und praktisch nicht nutzbar. Ein Workaround ist, dass Jabber Clients sich direkt verbinden, z.B. per http. Das bedeutet aber, dass einer offen im Netz sein muss ohne Firewall. Die Lösung ist p2p. Filesharing wird in Jabber Clients bald ganz normal sein dank frei verfügbaren p2p Socket Libraries.

Beispiel LLuna Video Icon: LLuna überträgt das mini Live-Video per HTTP. Der Computer, der das Video bereitstellt, benötigt ein Firewall-Loch und DynDNS. Das ist schwer für Normalanwender. Die Alternative wäre, alle Videodaten über die Jabber Verbindung zu leiten, was aus den oben genannten Gründen nicht geht. Die Lösung ist p2p.

Ich glaube, dass wir inzwischen verlernt haben, zwischen Computern Daten auszutauschen, weil wir darauf konditioniert sind, die Firewall-Probleme zu sehen. Es gibt unheimlich viele Anwendungen für p2p Kommunikation und wir werden wieder lernen p2p zu denken, wie in der guten alten Zeit, als das Internet noch offen war.

_happy_coding()

Alles freundlich

Der beliebteste Jabber Server der Welt jabber.org schickt jedem neu angemeldeten User eine persönliche Nachricht des Admins, dass er in der Jabber Welt willkommen sei und wo er mehr über Jabber erfahren kann. Das ist schön, denn dann ist die frische IM-Box nicht ganz so leer. Der Admin, der den Text verfasst hat, weisst ausserdem darauf hin, dass man darauf nicht antworten müsse.

Auch LLuna User sind Jabber User und neue LLuna User bekommen auch die Nachricht. Weil LLuna User nett sind, antworten Sie gerne und schicken ein freundliches "Hi" zurück an jabber.org. Der Server schickt alles weiter an seinen Admin und der Admin hat eine IM-Mailbox voll mit freundlichen "Hi"s neuer LLuna User.

Zum Glück erkennt der Admin, dass diese User von LLuna sind, weil LLuna netterweise die User ID mit "lluna_" prefixt. Er bittet den Projektleiter von LLuna die freundlichen "Hi"s abzustellen und der freundliche Projektleiter programmiert ein Stückerl Code ins LLuna, dass vermeidet, dass freundliche LLuna User aus Versehen indirekt den Admin von jabber.org nerven. Mit anderen Worten LLuna schickt jetzt keine mehr an eine JID ohne User ID. Und natürlich erscheint eine freundliche Dialogbox, die auf diesen Umstand hinweist.

Woher kommen die vielen LLuna User?
http://www.entwickler.com/itr/news/psecom,id,26289,nodeid,82.html
http://www.testticker.de/pcpro/news/netzwerke/news20060113013.aspx
http://www.computerwelt.at/detailArticle.asp?a=100401&n=5
http://www.ibusiness.de/aktuell/db/1137064280.html
GIGA Tool of the day

_happy_coding()

Webmobs Pressemitteilung

Schoen, wenn eine Pressemitteilung mal gelesen wird. Wir haben gestern Webmobs announced. Das war schon lange noetig. Das Web wird doch erst mit Menschen so richtig "Social". Webmobs, Virtuelle-Praesenz-LLuna ist Social Software vomn Feinsten. Gerade Blogger, die ja eh mir Ihren Lesern kommunizieren koennen auf dem Blog die Leser echt treffen. Auf irgendwelchen Themenseiten können sich ad-hoc Communities bilden und Mitglieder von bestehenden Communities treffen sich im Web, überall, nicht nur auf der Community-Page.

Virtuelle Praesenz, die Theorie: http://www.virtual-presence.org/
Webmobs, die Praxis: http://www.webmobs.de/
LLuna, eine Implementierung: http://www.lluna.de/

Web based Communities

Ein Paper wurde akzeptiert für die IADIS International Conference Web based Communities 2006. Das Paper ist deshalb wichtig, weil es zum ersten mal Anforderungen an ein weltweites System für Virtuelle Präsenz aufzählt und daraus eine Modellarchitektur ableitet. Die Architektur ist verteilt und protokollunabhängig. Der Kern ist das URL-Mapping von Dokument-URL (Webseite) zu Location-URL (Chatraum) bei der die Webseitenbetreiber eine Schlüsselrolle spielen und so ihr Hausrecht ausüben können.

_happy_coding()

Java is so 90s

Jahrelang kam man sich ja fast doof vor, noch C++ zu programmieren, weil in Java ja alles besser war. Aber es gibt Gleichgesinnte. Danke Slashdot.

Was hat uns eigentlich so gut an Java gefallen?
- Keine Pointer (nur Objektreferenzen, die null sein können, aha).
- Tolle Containerklassen dabei (bei C++ muss man STL nehmen, oder MFC oder wx oder ACE oder das selbstgebaute Framework, das eh jeder erwachsene Programmierer schon hatte).
- Kein delete, dafür Garbage Collector (schon toll im Normalfall, aber ich erinnere mich an Jigsaw Versionen, die nicht gingen, weil der GC buggy war).
- Threads ganz einfach, man muss nicht mal mehr wissen was in welchem Thread laeuft (fuers Protokoll, das ist Ironie. Wenn Programmierer nicht wissen wo was laeuft, dann sterben sie).
- JIT, eine gute Idee (um laaangsamen Code langsam zu machen).
- keine #defines und Templates (#defines, na ja, aber ohne Templates aus Containerklassen immer das Object hochcasten war schlicht beknackt).

Java war ein Schnellschuss. Die Marketingabteilung hat Goslings Spielzeugsystem breitgetreten, um die Welt mit Applets zu begluecken. Inzwischen kann man Java als Zwischenschritt auf dem Weg zu einem richtigen Framework betrachten. Manche nennen es Mono, andere .NET.

C#/NET hat genau die gleichen Features, wie Java. Eigentlich komisch, dass der GC bei .NET geht und der JIT lichtschnellen Code produziert. Ist MS besser, als Sun? Unwahrscheinlich. Die Konzepte waren in Java einfach noch nicht fertiggekocht. Die Programmierer haben sie zum 1., 2., 3. mal umgesetzt und noch nicht fertiggedacht. Bei .NET wurden die gleichen Konzepte zum 6., und 7. mal implementiert. Man hat Erfahrung gewonnen und aus Fehlern gelernt. Ein schoenes Beispiel fuer einen Software-Reifeprozess. Nicht nur Individualsoftware reift beim Kunden. Auch die Java Konzepte haben 8 Jahre lang bei Millionen Programmierern und Anwendern vor sich hingereift. Der Reifeprozess hat auch ergeben, dass #defines manchmal nötig und Templates doch praktisch sind.

Java musste einfach sein auf dem Weg. Da mussten wir durch. Jetzt sind wirs.

_happy_coding()

Graceful Degradation

Entwickler schreiben Software für ein Anwendungsszenario. Manchmal steht das Szenario im Pflichtenheft, in Meeting Notes, manchmal ist es nur im Kopf. Die wird dann so ausgelegt, dass sie den Anforderungen des Szenarios genügt und vielleicht etwas darüber hinaus. Aber manchmal wird Software später ganz anders eingesetzt, als vorgesehen. Aus Einzelplatzanwendungen werden Serveranwendungen mit 100 Usern. Aus kleinen Communities werden grosse Netze. Was über 1 MBit Leitungen funktionierte, soll auch auf 64 kB gehen, usw.

Mit Szenarioänderugen strapaziert man die Software und meistens dann auch die Geduld der User. Software kann nicht von Anfang an für alle Szenarien entwickelt werden. Das ist vor allem ein Budgetproblem. Ein Auto wird nicht zum Zementtransport verwendet. Und wenn, dann ist die Rückbank dreckig und es geht langsam. Software sieht nur flexibel aus, ist aber genauso für einen bestimmten Zweck gemacht, wie ein Auto.

Das Problem liegt eher darin, dass Software für User so aussieht, als ob andere Szenarien möglich sind. Das Auto sagt dem Benutzer (durch irreversibles Dreckigwerden der Rückbank), dass das Anwendungsszenario nicht passt oder zumindest, dass mit Beeinträchtigungen zu rechnen ist. An diesem Punkt können Entwickler ansetzen. Das User Interface kann sagen, wenn ein Szenario nicht zur Entwicklungsvorgabe passt. Wenn wir ein Serversystem für 20 User entwickeln, dann wird der Betrieb bei 30 zäh und alle beschweren sich. Wenn die Software ab Nummer 21 sagen würde, dass eigentlich zu viele User angemeldet sind, dann würde sich niemand wundern. Die Verantwortung wird damit abgewälzt auf die Beschaffungs-/Betriebsabteilung, die dafür sorgen muss, dass eine passende Software angeschafft wird. Und genau darum geht es uns als Entwickler.

Wir wollen nicht verantwortlich gemacht werden, dass Software falsch eingesetzt wird. Deshalb müssen wir (unsere Software) rechtzeitig zu erkennen geben, dass die Software strapaziert wird und mit Beeinträchtigungen zu rechnen ist. Wenn die Entwicklerin versucht, trotzdem den Betrieb aufrecht zu erhalten, dann ist das ehrenhaft, aber wenn es schief geht (Stichwort: zäh, Absturz), dann hat sie versagt. Deshalb: lieber die rechtzeitig gut sichtbar vor Überlastung warnen und weitermachen, als nichts sagen und zusammenbrechen. Denn Software, die zusammenbricht ist schlechte Software, zumindest in den Augen der User.

_happy_coding()