Posted by Carsten Bormann Thu, 23 Feb 2006 10:38:00 GMT
Es gibt jetzt ein Patent zu AJAX (genauer: rich-media applications via the internet).
Das wird in den Blogs noch genug diskutiert werden, ich spare mir das hier. Eines ist sicher: Die Welt braucht Erfinder wie Neil Balthaser!
Zum Glück gibt es in Europa (noch) keine Softwarepatente. (Wenn nur die Patentämter das auch wüßten…)
Posted by Carsten Bormann Mon, 20 Feb 2006 22:44:00 GMT
Einen Klick wert: Übersichtliche Spickzettel für das Arbeiten mit der JavaScript-Bibliothek prototype.
Posted by Olaf Bergmann Wed, 25 Jan 2006 17:40:00 GMT
Gerade noch wurden die Autoren des AJAX-Buchs geschmäht, weil sie ein Grundlagenwerk verfaßt haben, das auch über die rasante Entwicklung neuer Technologien hinaus bestehen soll (ob das wirklich so ist, wird sich natürlich erst mit der Zeit zeigen), da kündet die Software-Schmiede in Redmond von einer wesentlichen Vereinfachung für Entwickler von Anwendungen mit AJAX-Funktionalität. Wie kurze Zeit später auch in allen deutschsprachigen IT-Newstickern, Blogs und Foren zu lesen, wird der Internet Explorer ab Version 7 über ein natives XMLHttpRequest-Objekt verfügen. Das ist insofern nützlich, da AJAX-basierte Anwendungen nunmehr ohne das Einschalten von ActiveX im Internet Explorer auskommen könnten – wenn da nicht die große Nutzerbasis der früheren Versionen wäre. Wie auch das Code-Fragment im MSDN-Blog zeigt (s. o.), wird die Entwicklergemeinde auch in Zukunft nicht ohne Feature-Sniffing auskommen. Profitieren werden von dieser Entwicklung in erste Linie die Nutzer, die über einen Browser mit moderneren Eigenschaften verfügen werden und ein kleines Stück Sicherheit gewinnen, wenn sie ActiveX wieder deaktivieren.
Wer heute also behauptet, die (Quasi-)Standardisierung von AJAX-Technologien sei in dem letzten halben Jahr vorangeschritten, der übersieht eine wesentliche Anforderung, die das Web 2.0 mit sich bringt: Usability. Wie schon zu Zeiten von HTML 3.2 interessieren sich Nutzer überhaupt nicht dafür, welchen tollen Eigenschaften die unterliegenden Technologien mit sich bringen – sie möchten vor allem eine funktionierende Anwendung, die ihr Problem löst. Trotz aller Euphorie über neue AJAX-Frameworks und neue Features in manchen Browsern bleibt es also dabei, daß Web-Entwickler vor allem verstehen müssen, was in ihrer Anwendung passiert. Das Wasser, mit dem dabei gekocht wird, hat sich in dem letzten halben Jahr aber nicht geändert.
Posted by Carsten Bormann Mon, 19 Dec 2005 20:26:00 GMT
Es ist die Zeit der Jahresrückblicke. Hier ein kleiner Beitrag.
Oktober 2005 war der Monat der Haßtiraden. Ein Mem, ein sich unaufhaltsam durchsetzender neuer Begriff mußte zerstört werden. Selbst sonst als kühle Denker bekannte Autoren wie Joel Spolsky verstiegen sich in heilige Schwüre, nie wieder über Web 2.0 zu schreiben.
Muss man ja auch nicht, aber warum dann erst einmal darüber schreiben und dann versprechen, dass man es nie wieder tun wird?
Weil „Web 2.0“ ein mächtiger Gedanke ist. (Mächtig genug, um bei Microsoft ein weiteres „Sea-Change“-Memo samt Produkt-Vorankündigungs-FUD auszulösen — das gibt es nur alle fünf Jahre.)
„Web 2.0“ war zunächst nichts anderes als der Name einer erfolgreichen Konferenz von O’Reilly. Marketing also. (Wie bei AJAX ärgern sich natürlich viele darüber, daß nicht sie es waren, die den gängigen Begriff für etwas geprägt haben, was sie vielleicht schon vorher gedacht haben.)
Es ist aber noch mehr dahinter: Die nackte Angst vor Bubble 2.0. Nicht schon wieder inhaltsleere Buzzwords, bei denen Millionen ihre Ersparnisse verlieren und wenige reich werden. (Die Bubble 1.0 ist allerdings noch genug im Gedächtnis, daß das schon nicht passieren wird.)
Wir Techniker haben natürlich eine klare Abneigung gegen unscharfe Begriffe. Niemand kann heute definieren, was Web 2.0 eigentlich genau ist.
Ist das schlimm? Schnell antworten: Wann begann nach dem Mittelalter die Neuzeit?
Ähnlich wie die „Neuzeit“ ist auch Web 2.0 ein (kleiner) Epochenübergang, oder zumindest die Kombination aus Renaissance und Innovation, mit der er beginnt. Keine einzelne Entwicklung ist Web 2.0 — es geht um die Kombination mehrerer Entwicklungen, die teils voneinander unabhängig sind, sich teils gegenseitig bedingen und verstärken. Insgesamt kommt eine (Web-)Welt heraus, die sich einfach deutlich von der davor unterscheidet.
Selbst Paul Graham, seines Zeichens querdenkender Web-Pionier und einer der Buzzword-resistenteren Autoren dieser Welt, sieht inzwischen, daß da etwas ist. In seinem äußerst lesenswerten Artikel reduziert er Web 2.0 auf drei Dinge:
AJAX (das Web als Plattform für Anwendungen);
Demokratie (und damit meint er wohl primär, die gesammelte Intelligenz der Menschen auch zu nutzen);
Benutzer nicht mehr mißhandeln.
Oh, und dieser Tage haben wir sie noch einmal wieder, die Diskussion. (Die Zeit der Jahresrückblicke und der guten Vorsätze für 2006, halt.)
Web 2.0 findet statt. Vielleicht nicht nachhaltig unter diesem Namen, aber das ist nicht so wichtig. Wir wissen auch noch nicht ganz genau, wie es einmal aussehen wird, aber klar ist schon, dass AJAX eine wichtige Rolle dabei spielen wird.
Posted by Carsten Bormann Wed, 14 Dec 2005 12:36:00 GMT
Vor ein paar Stunden hat die viel beachtete neue Web-Entwicklungsumgebung Ruby on Rails die Version 1.0 erreicht. 1.0 wie in „Firefox 1.0“, nicht wie in „Windows 1.0“.
Rails demontiert gerade mit erstaunlicher Geschwindigkeit die Vormachtstellung der bisherigen Alpha-Tiere der Web-Entwicklung — mindestens in den Köpfen, aber zunehmend auch in großen missionskritischen Umgebungen.
Was hat die Freigabe von Rails 1.0 mit AJAX zu tun? Rails war das erste große Web-Framework, das AJAX als selbstverständlichen Aspekt mit unterstützte. Mit Rails 1.0 sind insbesondere aber auch die JavaScript-Bibliotheken Prototype 1.4 und Scriptaculous 1.5 freigegeben worden. Diese Bibliotheken haben jetzt eine Menge fokussiertes Bug-Fixing hinter sich; zu erwarten ist eine recht stabile Basis für fortgeschrittene AJAX-Anwendungen — auch für solche, bei denen die Serverseite (noch?) nicht Rails heißt.
Zurück zu Rails:
gem install rails --include-dependencies ist angesagt.
Studierende an der Universität Bremen können sich übrigens
schon mal auf meine Lehrveranstaltung „Produktive Web-Entwicklung“ im
Februar freuen. (Als nächstes auf der Agenda: Kurse, die
auch außerhalb der Universität zur Verfügung stehen.)
Posted by Carsten Bormann Tue, 29 Nov 2005 08:06:00 GMT
Will man AJAX für die Echtzeit-Darstellung von Informationen benutzen, so möchte man, daß der Client vom Server über jede relevante Zustandsänderung sofort informiert wird. Dafür eignet sich am besten eine HTTP-Verbindung, die vom Browser offengehalten wird, und in die der Server neue Daten einspeist, sobald diese verfügbar sind.
Dabei gibt es jedoch zwei Klassen von Problemen:
Die heute üblichen Web-Server wie Apache sind nicht sehr gut darin, viele gleichzeitig offene Verbindungen zu verwalten. Man möchte eigentlich die Echtzeit-Verbindungen trennen von den HTTP-Verbindungen, über die große Datenmengen geschaufelt werden. So verwendet S6 einen Synchronisationsserver, der mitteilt, wann ein neuer Zustand vorliegt — der Client kann dann (über eine separate Verbindung) Daten nachfordern. (Bei S6 ist dieses Nachfordern noch nicht in Benutzung, weil das zugrundeliegende System S5 die Präsentation vorweg als ganzes lädt, aber man kann sich S6 durchaus auch mit mehr AJAX-Funktionalität vorstellen.)
XMLHttpRequest läßt aber aus Sicherheitsgründen nur Zugriffe auf dieselbe Domain zu, von der auch die Seite selbst stammt — eine sinnvolle Erweiterung der same origin policy, der wichtigsten Grundlage der JavaScript-Sicherheit. Bei S6 bedeutet das, daß die inhaltsschweren HTTP-Zugriffe vom selben Server beantwortet werden müssen wie die Synchronisations-Zugriffe. Das ist auch der Grund für den etwas instabilen Aufbau des Demo-Servers:
Ein Webrick-Server unter http://tzi.org:2000/s6.html liefert sowohl Inhalte als auch Synchronisation. Webrick ist aber als Server für Inhalte nicht besonders effizient (außerdem belegt der Apache-Server den Port 80 auf tzi.org, so daß Webrick auf den wenig Firewall-freundlichen Port 2000 ausweichen mußte).
Als Alternative wird die S6-Demo deswegen unter http://www.tzi.org/~cabo/s6/s6.html auch über Apache angeboten. Im Proxy-Modus werden die Synchronisationsanfragen an den Webrick-Server weitergeleitet. Das bedeutet aber, daß jeder S6-Follower eine andauernde Verbindung zum Apache-Server aufrechterhält (was unser Webmaster zum Glück noch nicht recht wahrgenommen hat :-). Nicht skalierbar.
Selbst wenn bessere Proxy-Server das serverseitige Problem mit der durch die XMLHttpRequest-Sicherheit geforderten Serverbindung lösen würden, gibt es noch einen anderen Grund, Synchronisationsanfragen von Inhaltsanfragen trennen zu wollen:
Um die Web-Server nicht zu überlasten, haben Browser meist eine Begrenzung für die Anzahl der HTTP-Verbindungen, die gleichzeitig zu einem Server geöffnet werden — dieses Maximum liegt heute im allgemeinen bei zwei. Wird davon eine für Synchronisationsanfragen dauerhaft belegt, wird die andere zum Flaschenhals. (Und hat ein Client erst einmal zwei Echtzeit-Anwendungen vom selben Server offen, geht für den Client auf diesem Server gar nichts mehr.)
Auch hier wäre es also höchst sinnvoll, XMLHttpRequest-Anfragen auf
mehrere Domänen verteilen zu können: Inhalte von www.tzi.org,
Synchronisationsanfragen von sync.tzi.org.
XMLHttpRequest weigert sich aber
(aus guten Gründen) hartnäckig, Domain-übergreifende Anfragen
zuzulassen. (Eine etwas offenere Sicherheitspolitik wird zwar
gelegentlich diskutiert, aber das nützt natürlich nichts für die
nächsten ein, zwei Jahre.)
Abe Fettig, seines Zeichens Entwickler der interessanten Plattform JotSpot Live (mehr dazu in einem anderen Blogpost), beschrieb gestern abend seinen Ansatz, mit der JavaScript-Eigenschaft document.domain die beschriebenen Sicherheitseinschränkungen von XMLHttpRequest teilweise zu umgehen.
Die Eigenschaft document.domain stellt seit NetScape Navigator 2.0
eine Möglichkeit zur Verfügung, die same origin policy auf mehrere
Server mit einer gemeinsamen Haupt-Domain auszudehnen: In unserem Fall
(www.tzi.org und sync.tzi.org) würde man also document.domain
auf tzi.org stellen, und dann sind Cross-Domain-Zugriffe möglich.
Ganz so einfach ist es bei XMLHttpRequest allerdings nicht: Die Domain
muß genau übereinstimmen!
Die grobe Idee von Fettig: Der JavaScript-Code mit dem XMLHttpRequest für den zweiten Server wird in
einen iframe verfrachtet, der im Gegensatz zum Hauptdokument von
dieser zweiten Domain (z.B. sync.tzi.org) geladen wird.
Das Problem ist damit darauf reduziert, eine Kommunikation zwischen
iframe und Hauptdokument (geladen z.B. von www.tzi.org) zu
ermöglichen — und hier kommt uns document.domain zu Hilfe.
Der naheliegende Ansatz ist es, im iframe zunächst den XMLHttpRequest
durchzuführen, dann document.domain auf die gleiche übergeordnete
Domain zu stellen, die man vorher schon im Hauptdokument eingestellt
hat (in unserem Fall wäre das tzi.org).
Nach dieser Änderung kann man vom iframe aus auf das
Hauptdokument zugreifen, um das Ergebnis mitzuteilen.
Problem: nachdem im iframe document.domain auf den Wert tzi.org umgesetzt ist,
funktioniert natürlich kein weiteres XMLHttpRequest zu sync.tzi.org
mehr. Mein Ansatz wäre nun wohl gewesen, für weitere Anfragen dann eben
weitere iframes zu erzeugen.
Fettig hat hingegen einfach probiert,
document.domain wieder auf den alten Wert (in unserem Beispiel wäre
das sync.tzi.org) zurückzusetzen. Siehe da: In IE und
Safari/Konqueror funktioniert das auch. In Mozilla/Firefox und Opera leider
nicht (was ich für eine valide Interpretation der
same origin policy halte), und da kommt schon der nächste Trick: Fettig
hebelt die Kommunikationsbeschränkungen zwischen Hauptdokument und
iframe einfach ein bißchen aus, indem er ein weiteres iframe
dazwischenschiebt (ebenfalls aus sync.tzi.org geladen), das das eigentliche
Kommunikations-iframe erzeugt, dort eine Variable installiert, die auf
eine im Zwischen-iframe definierte Closure (JavaScript-Funktion)
verweist.
Im Zwischen-iframe kann dann document.domain auf tzi.org gesetzt
werden, um mit dem Hauptdokument zu kommunizieren; das
Kommunikations-iframe verbleibt in der Domain sync.tzi.org.
Mozilla/Firefox (und nur dieser)
hat nichts dagegen, und die Kommunikation flutscht über diesen kleinen
Umweg. (Fettig hat noch keine Lösung für Opera, aber das ist ihm
nicht so wichtig.) Jetzt brauchen wir nur noch eine Methode, um
zwischen den beiden Lösungen umzuschalten: die erste wirft ja bei
Mozilla/Firefox eine Ausnahme; die wird abgefangen und es wird auf die Mozilla-Alternative umgeschaltet.
Was für ein Hack, aber: Today’s “hack” is tomorrow’s “standard”.
Ich würde mich bei der ganzen Sache wesentlich wohler fühlen, wenn die für Mozilla/Firefox erforderliche Kommunikation über die Zwischeninstanz mit dem Kommunikationskanal Closure sich nicht so sehr wie ein Sicherheitsloch anfühlen würde, das auch für bösere Zwecke genutzt werden kann und deswegen in zukünftigen Mozilla/Firefox-Versionen wieder geschlossen wird. Als nächster Schritt ist jetzt wohl eine Runde vernünftiger Security-Analysen angesagt.
Posted by Carsten Bormann Sun, 27 Nov 2005 15:29:00 GMT
Viel Gerede um Windows Live Mail. Am häufigsten genanntes Feature: AJAX. Endlich wie Gmail‽
Einspruch, Euer Ehren: Windows Live Mail funktioniert offenbar nur mit Internet Explorer. Was nicht in Firefox funktioniert, ist aber kein AJAX.
Erinnern wir uns: Die wichtigste Neuerung des AJAX-Ansatzes gegenüber bisherigen Versuchen, Rich Internet Applications zu bauen, war ja, standardbasiert vorzugehen. Keine neuen Plugins, keine neuen Browser. Standardbasierter als Firefox wird ein Browser wohl kaum ⇒ was in Firefox nicht geht, ist vielleicht interessant, aber jedenfalls kein AJAX.
Hoffen wir, daß Microsoft bei der Ankündigung „Firefox support is coming soon“ in Wirklichkeit gemeint hat: „Web support is coming soon“…
Posted by Carsten Bormann Sat, 22 Oct 2005 18:46:00 GMT
Schlußfolgerungen aus Web-basierten Umfragen sind stets mit besonderer Vorsicht zu behandeln. Nichtsdestoweniger finde ich die Ergebnisse einer Web-Umfrage eines Burton-Group-Mitarbeiters unter AJAX-Entwicklern (angekündigt vor ein paar Tagen im Ajaxian Blog) beeindruckend.
Knapp ein Drittel der Teilnehmer berichten, sie hätten AJAX-Anwendungen bereits im Produktionsbetrieb. Ein weiteres Drittel entwickelt schon; ein weiteres Viertel probiert offenbar noch (und ein paar denken noch nach).
Was sind nun die Serverumgebungen, mit denen AJAX-Techniken umgesetzt werden? Die größte Gruppe benutzt PHP (über 40 %), dicht gefolgt von Java (35 %). Wer gedacht hätte, AJAX würde nur in hypermodernen Entwicklungs-Umgebungen wie Ruby on Rails eingesetzt (15 %), wird überrascht, selbst die .NET-Gruppe hatte mit 18 % mehr Antworten.
Schließlich war noch die Frage nach dem Client-seitigen Toolkit von
Interesse. Die größte Gruppe (40 %) tinkert direkt mit
XMLHttpRequest, eine Vorgehensweise, die wir im AJAX-Buch
nicht empfehlen. Die zweitgrößte Gruppe (23 %) benutzt
prototype, was gegenwärtig auch unsere Empfehlung ist, nicht
zuletzt wegen script.aculo.us, der wunderbaren Zusatzbibliothek
von Thomas Fuchs, die 18 % weitere Nennungen bekommen hat (ebenso
wie Rails mit 10 %, was aber ja auch nichts anderes als prototype und script.aculo.us
heißt). Auf über 10 % kamen auch noch die beiden Toolkits DWR
(Java-Umgebung) und Dojo. Einen Ehrenpreis bekommt mit 8 %
schließlich die deutsche Entwicklung Ajax.NET; danach kommt der long tail der anderen Toolkits.
Gibt es, wie im Buch vorhergesagt, schon so etwas wie eine Konsolidierung der Toolkits?
Posted by Olaf Bergmann Fri, 21 Oct 2005 02:31:00 GMT
Anfang Oktober fand in San Francisco zum zweiten Mal die internationale Konferenz zum Web 2.0 statt. Wie bei Konferenzen zu aktuellen Modethemen üblich, waren unter den Ausstellern auch viele neu gegründete Unternehmen, die den Markt mit frischen Ansätzen bereichern. Beispiele für Startups, die auf AJAX-Technologie auf der Clientseite webbasierter Anwendungen setzen, sind Meebo und Zimbra. Beide Unternehmen haben sich im weitesten Sinne auf Messaging-Anwendungen mit Web-Interface spezialisiert, ein Feld, das auch Google Talk besetzen möchte.
Mit Instant Messaging (IM) wird ein Modethema der vergangenen Jahre aufgegriffen und ajaxifiziert. Ein wesentliches Merkmal von klassischen IM-Anwendungen ist der eingebaute Presence-Dienst, der Auskunft über die Verfügbarkeit von eingetragenen Nutzern erteilt. Für jeden Kontakt im Adreßbuch der IM-Anwendung (oft Roster oder Buddy-List genannt) kann man sofort sehen, ob diejenige Person gerade erreichbar ist oder nicht gestört werden möchte.
Klassische IM-Protokolle wie Jabber/XMPP oder SIMPLE unterscheiden sich von webbasierten Ansätzen durch ihre push-basierte Architektur; da jeder Teilnehmer einen eigenen Serverprozeß aufsetzt, können Nachrichten bei Bedarf an den betreffenden Teilnehmer gesendet werden. In einer Client/Server-Architektur hingegen müssen die Clients regelmäßig Anfragen stellen, um neue Informationen zu erhalten.
Dies ist auch der Ansatz, der im AJAX-Buch angedeutet
wird. Mit dem Ajax.PeriodicalUpdater aus der Bibliothek
Prototype lässt sich eine Buddy-List sehr einfach
aktualisieren. Alternativ ließe sich auch der PeriodicalExecuter
dafür einsetzen, allerdings lässt sich dieser nicht so ohne weiteres
stoppen, wenn er erst einmal läuft – der Browser wird dann sehr
schnell zum Speicherfresser.
Auf den ersten Blick erscheint das Polling gegenüber den push-basierten Lösungen nicht sehr attraktiv. Doch die Ende-zu-Ende-Kommunikation hat einen großen Nachteil: Sie harmoniert nicht gut mit Middleboxes, also Geräten, die sich zwischen Sender und Empfänger einer Kommunikationsbeziehung befinden und den normalen Protokollablauf beeinflussen können. Die bekanntesten Vertreter dieser Art sind NATs und Firewalls. Beide haben ihre Berechtigung, machen eine reibungslose Kommunikation aber sehr schwer. Das Ergebnis sind Keep-Alive-Mechanismen und Verrenkungen wie STUN, um von außerhalb erreichbar zu sein.
Webbasierte Anwendungen können dieses Problem getrost vernachlässigen: Sobald Web-Traffic durch die Firewall gelassen wird, was selbst in den meisten Unternehmen heutzutage übliche Praxis ist, kann die bidirektionale Kommunikation über TCP beginnen. Bereits vor einigen Jahren haben Web-Services diese asymmetrische Kommunkationsbeziehung genutzt, um Schwierigkeiten mit Firewalls und NATs zu umgehen. Und das ist auch der Grund, warum SOAP fast ausschließlich über HTTP transportiert wird…
Keine Frage, Polling über HTTP gibt es schon lange und wird es immer
geben. Das XMLHttpRequest-Objekt wird diesen Aspekt aber wieder
stärker in den Vordergrund rücken. Mit welchen Lasten muss ein
Server-Betreiber nun plötzlich rechnen? Wie viele Filedeskriptoren
sind gleichzeitig offen zu halten? Welche Bandbreite erfordern die
Antworten? Wie unterscheidet man das erwünschte Polling von einer
DOS-Attacke?
Posted by Carsten Bormann Tue, 18 Oct 2005 07:05:00 GMT
Wer kennt das Problem nicht: Man telefoniert mit jemandem (oder gleich mit einer ganzen Telefonkonferenz) und möchte seine Ausführungen mit ein paar Folien untermalen. Wie bekommt man es hin, daß die Gesprächspartner im Laufe der Präsentation immer jeweils dieselbe Folie sehen wie man selbst?
Einsatz für AJAX.
Man nehme:
Ergebnis: S6, Synchronized Simple Standards-based Slide Show System.
Die Benutzungsschnittstelle folgt der bewährten Alternative:
Führe (Lead)
Der Browser des Vortragenden teilt dem Synchronisationsserver jeden Folienwechsel mit.
Folge (Follow)
Browser von Zuhörern werden vom Synchronisationsserver sofort benachrichtigt, sobald der Vortragende auf eine andere Folie schaut als sie selbst, und schalten dann ebenfalls auf diese Folie um.
Geh aus dem Weg (Get out of the way)
Will man unabhängig vom Vortragenden blättern, kann man „aus dem Weg gehen“ — die Aktionen des Vortragenden haben dann keinen Einfluß mehr auf den Browser.
Lädt man eine S6-Präsentation in den Browser, ist man zunächst in letzterem Modus (das ist aber mit einer Zeile JavaScript konfigurierbar). Tippt man ein „L“, dann betritt man den Führungsmodus, mit „F“ kommt man in den Folgemodus (meine Folien haben diese Information als Hilfetext auf der ersten Seite). Mit „G“ geht man (wieder) aus dem Weg. (Das ganze probiert man am besten vor der Telefonkonferenz mit ein paar Browserfenstern aus. Getestet in IE6, Firefox, Safari. Opera hat seinen eigenen merkwürdigen Slideshow-Modus, mit dem ich noch nicht ganz klar komme.)
Der Synchronisationsserver kann mehrere Folienpräsentationen gleichzeitig synchronisieren — der URI der Präsentation dient als eindeutiger Bezeichner einer Gruppe (notfalls kann man mit unterschiedlichen Fragmentbezeichnern, die von S5 im allgemeinen ignoriert werden, mehrere Sitzungen mit demselben Foliensatz voneinander trennen).
Die Idee, S5 um Synchronisation zu erweitern, ist übrigens so gut, daß auch jemand anders sie inzwischen gehabt hat. Im Vergleich zu S6 fehlt der Echtzeitaspekt (der Server wird einfach alle 2.5 Sekunden angefragt), das Multiplexing über den URI, und die klare Trennung der verschiedenen Betriebsarten. Dafür hat Teemu Arina auch den inkrementellen Aufbau der Folien in S5 adressiert, wozu ich noch nicht gekommen bin, und seine Version läuft auch in einem normalen Web-Server wie Apache.
Eric, Teemu und ich sind jetzt dabei, das alles zu sortieren. Vielleicht kann ich demnächst über eine Release berichten…
(Update: Die Links auf den experimentellen Web-Server stimmen jetzt. Danke, Oliver. Mental note: Niemals 10 Minuten vor einer Vorlesung bloggen :-)
Older posts: 1 2
