10. Mai 2008

Schach mit Google Docs

Man kann ein ge-share-tes Google Spreadsheet als Schachbrett benutzen. Alle (beide) Teilnehmer können live sehen was der andere macht.

Gezogen wird mit "Ausschneiden" und "Einfügen". Auf farbige Schachfelder verzichten wir deshalb lieber, sonst kopiert man den Hintergrund mit.

Die Spieler sind als weblins da und können chatten. Das wäre sogar in Google Docs gegangen mit "Chat about this spreadsheet". Aber Sprechblasen sind netter.

9. Mai 2008

weblin.lite Bookmarklet

This bookmarklet toggles weblin.lite for the current page. It en-lite-ns the current page by adding a URL prefix. If the page is already en-lite-ned, then it removes the prefix. You can add it to your browser as a bookmark.

Bookmarklet: weblin.lite


For those who are interested, this is the code:

var s = new String(top.document.location);
var p = 'http://lite.weblin.com/';
if (s.substr(0, p.length) == p) {
s = s.substr(p.length);
var b = false;
while (!b && s.length != 0) {
if (s.substr(0,1) == '?') {
b = true;
}
s = s.substr(1);
}
var n = s.search(/&weblin\.lite&/);
if (n != -1) {
s = s.substr(0, n);
}
top.document.location = s;
} else {
top.document.location = p + '?' + s + '&weblin.lite&referer=bookmarklet';
}



_happy_coding()

7. Mai 2008

Twitteraktivität

Meine Twitteraktivität.

Sieht nach ausreichend Schlaf aus, aber das Mittagessen ist etwas unregelmässig.

6. Mai 2008

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".

30. April 2008

Me.dium wird zum Social Instant Messanger


Me.dium konzentriert sich auf Freunde. Die Me.dium Sidebar zeigt wo Freunde sind und was sie machen. Neue Leute im Web treffen auf den Seiten wo ich gerade bin entfällt (!). Es soll später wieder kommen, aber Me.dium scheint sich abzuwenden von Virtueller Präsenz, hin zu einer Art social IM. Die neuen Funktionen sind ähnlich zum Flock Browser.

22. April 2008

Simple Remote Procedure Call - Batch

SRPC-Batch is an extension to SRPC. The batch-mode carries multiple remote procedure calls in a single transaction. The global "Method" indicates the batch mode. Individual RPCs are prefixed by an index, e.g. "1:Method=...".

Example:

  1. C: Method=Batch
  2. C: 0:Method=GetQuote
  3. C: 0:Symbol=GOOG
  4. C: 1:Method=GetQuote
  5. C: 1:Symbol=APPL
  1. S: Status=1
  2. S: 0:Status=1
  3. S: 0:Average=123
  4. S: 0:Low=121
  5. S: 0:High=125
  6. S: 1:Status=1
  7. S: 1:Average=456
  8. S: 1:Low=455
  9. S: 1:High=457

Rationale:

In rare cases clients want to execute not just one, but multiple commands. This saves network bandwidth and roundtrip time, especially on SSL connections. It also allows a batch of RPCs to be executed consecutively. We are using batch commands also to store them in the database and execute multiple commands on request.

Details:

  • the request has a "Method=Batch",
  • the request contains multiple remote procedure calls,
  • parameters of individual RPCs are prefixed by an index N and a colon: "N:", e.g. "1:",
  • the index indicates individual RPCs,
  • all parameters of an individual RPC have the same index,
  • the index starts with "0" (zero),
  • each RPC has a "Method" parameter (1:Method=...),
  • meta parameters as usual: "1:Symbol/Encoding=cstring",
  • the response has a "Status=..." (0/1) indicating success of the batch-parser,
  • the response carries a "Status" for each individual request,
  • result parameters use the same syntax as the requests (1:Status=...),
  • RPC results have the the same index as the corresponding request,
  • the receiver executes ALL commands and returns their result even if some fail.

Comments:

  • the batch-extension is optional. It is not required for receivers. Better ask your server if it is supported,
  • in additon to "Method", the request may have additional "global" parameters.

8. April 2008

Virtual Worlds 2008

Eigentlich wollte ich ein paar gemütliche Tage auf der Virtual Worlds 2008 verbringen. Fachvorträge hören und nebenbei in Ruhe was coden. Dann aber haben wir kurzerhand beschlossen, auf der zugehörigen Expo einen Stand zu machen und vorbei war es mit der Ruhe. Wir hatten zu dritt so viel zu tun auf dem weblin Stand, dass ich nicht eine einzige Session besucht habe. Alle drei waren ständig am Reden und Vorführen. Daniel hatte in Flash ein geniales Demo-Tool gebaut mit dem wir die wichtigsten Features und Anwendungsbeispiele aufrufen konnten. Zwischendurch natürlich auch immer wieder Life-Demos von Client und Lite trotz langsamem WLAN. Meistens waren die weblins schneller da, als die Webseite.

Insgesamt waren auf der Konferenz ca. 1200 Teilnehmer, alle Fachbesucher, keine Beutelratten. In der Expo war fast alles was Rang und Namen hat in der virtuellen Welt. Die großen Welten: SL, There, Habbo, ActiveWorlds, die großen Agenturen: Electric Sheep, Millions of Us, und viele andere Welten, Dienstleister, Plattformen und Engines (z.B. Metaverse, BigWorld, VastPark, elektrotank, iLemon, 500 Mirrors), Payment-Dienste, Avatar-Generatoren (z.B. Cyber-Extruder), andere Avatarsysteme (z.B. weblin, xtra-normal), usw. Auch neue 3D Welten waren da und/oder wurden sogar auf der Konferenz "gelauncht" wie mycosm.

Second Life öffnet sein Grid und erlaubt anderen (vor allem IBM) SL Server selbst zu betreiben. IBM versucht seit einiger Zeit "was mit virtuellen Welten" zu machen, hat mehrere eigene Welten, und will den Content selbst hosten. Bei einer "kleinen Firma" Content hosten reicht eben nicht für Dienstleister, wie IBM, die gegenüber Ihren Kunden dafür gerade stehen muss.

Multiverse bietet jetzt sogar parallel 3D (exe-Client) und 2D (Flash) Interfaces für die gleiche Welt an. Wenn sich eine Figur in der 3D Welt bewegt sieht man die das auch im 2D Viewer. Das ist technisch interessant, aber der Content wird nicht automatisch konvertiert. Man sagt, es gibt doppelt gemacht werden. Multiverse ist damit Metaplace (Areae, Raph Koster) voraus. Areae bietet zuerst nur 2D-Flash, später 3D. Areae war durch Jason Hable vertreten. Mit dem allgegenwärtigen Corey Bridges von Multiverse hat der sonst allgegenwärtige Raph Koster einen ebenbürtigen Mitspieler.

Überhaupt gibt es immer mehr virtuelle Welten, die sich in Webseiten einbetten lassen. Die meisten davon machen eine "anständige" Architektur, und nur "zuerst mal" einen Flash Client weil Einbetten in Webseiten, Blogs und Social Network Homepages gerade so cool ist, siehe Areae, Multiverse, Ogoglio, Media Machines. Daneben gibt es natürlich die für Flash gemachten Welten: Habbo, Barbie Girls, aber auch Freggers, DinoKids, MyMiniLife, SceneCaster und viele viele andere.

Sehr cool: xtra-normal, ein scriptbarer Movie-Generator.