Zurück von der ETech

Posted by Carsten Bormann Sun, 12 Mar 2006 06:22:00 GMT

Montag bis Donnerstag dieser Woche fand in San Diego die diesjährige Auflage der O’Reilly-Konferenz „Emerging Technology“ statt.

Meine Präsentation zu PANIC-Mode fand am Donnerstag in einem völlig überfüllten Raum statt. Sie ist wohl ganz gut angekommen, aber wurde natürlich völlig überschattet von Steve Yens unmittelbar darauffolgender Präsentation zu Trimpath und NumSum. Eine eindrucksvolle Demonstration dafür, daß JavaScript eine vollwertige Programmiersprache ist, mit der man auch nichttriviale Systeme schreiben kann. (Ein Problem dabei ist heute oft, daß dieselbe Geschäftslogik, die clientseitig in der JavaScript-Anwendung abläuft, auch auf Server-Seite implementiert sein muss. Steve Yens Idee: mehrfaches Programmieren dadurch vermeiden, daß man denselben Code, der im Browser läuft, im Server durch den JavaScript-Interpreter Rhino ausführen läßt.) Leider reichte die Zeit nicht für seine ganze Präsentation. Nachdem der sichtbarste Online-Nachfolger von Microsoft Word writely gerade durch Google übernommen wurde, kann man Steve mit seinem Excel-Nachfolger nur ähnliches Glück wünschen.

Zur Konferenz selbst:

Tim Bray hatte ein ähnlich gemischtes Gefühl wie ich. Die Produktpräsentationen waren zum Teil wirklicht wenig erhellend; andererseits liefen in den Tracks durchaus auch interaktive Segmente unter „Products and Services“, die ich nicht hätte missen wollen. Zur Organisation insbesondere des letzten Tages gab es bereits einen vernichtenden Artikel, dem ich nichts hinzuzufügen habe. (Vielleicht das nächste mal das Hotel rechtzeitig buchen, so daß die ganze Zeit geeignete Räume für die Konferenz zur Verfügung stehen?) Natürlich findet der wichtigste Aspekt von Konferenzen außerhalb der Vortragssäle statt, und über diesen Bestandteil kann ich mich nicht beklagen.

Was waren (außer Steve Yens Auftritt) die Highlights?

  • microformats. Schon einige Zeit ein Thema, jetzt definitiv heiß.
  • RSS ist als Informationsbus des Web inzwischen unumstritten, am besten in seiner standardisierten Form Atom (nur Microsoft scheint letzteres noch nicht ganz begriffen zu haben). Interessant z.B. auch, wie Ning seine gesamten Daten über Atom-Feeds anbietet.
  • Ein Microsoft-CTO, der seine neueste Erfindung in Firefox demonstriert. (Der Microsoft-Mann, der später geschniegelt im Dreiteiler auftauchte, war auch nicht schlecht, aber seine Präsentation habe ich bereits wieder vergessen.)
  • Für den Vortrag von Bruce Sterling kam ich leider terminbedingt zu spät — alle sagten aber, er sei sehr, sehr gut gewesen. Ich hoffe, da wird noch mehr gebloggt.
  • cutetracker, eine von vielen Anwendungen in Ning.
  • Clay Shirky versucht, Entwurfmuster herauszuarbeiten, um eine Site mit benutzergenerierten Inhalten vor dem Abstieg in Flamewars o.ä. zu bewahren — u.a., um „die Leser vor den Schreibern zu schützen“.
  • „Wenn die ungelesenen Einträge im Feedreader heute noch nicht wichtiger erscheinen als die im Mailreader — sie werden es bald sein“ (Rael Dornfest frei zitiert nach ruminate).
  • Die EFF hat die wichtigen Gerichtsverfahren der nächsten Jahre vorhergesagt. Darunter: „PatentTrollCo verklagt AJAX-Sites“ — da es nicht schwer sein dürfte, bestehende Patente solange umzuinterpretieren, bis sie irgendwann AJAX-Techniken betreffen, lohnt sich Patent-Wegelagerei im „long tail“ der kleinen Sites (die bei der Wahl, 5000 Euro Lösegeld zu zahlen oder einen Rechtsstreit wegen eines dubiosen Patents zu riskieren, nicht lange nachdenken müssen). Glücklicherweise ist der anwesende EFF-Rechtsanwalt Jason unter anderem für das Patent-Busting bei der EFF.
  • (Off-Topic:) Jeff Han hat sein „Multi-Touch“-Interface demonstriert. Überzeugt hat mich vor allem, wie man alle drei 2D-Transformationen (Verschieben, Skalieren — „Zoom“, Rotieren) auf einer virtuellen Oberfläche mit intuitiv wirkenden Gesten abbilden kann. Und Hut ab vor der genial einfachen technischen Realisierung…

Darüber hinaus konnte, wer das noch nicht woanders mitbekommen hat, sich über anstehende Themen wie Identity 2.0, oder auch über Mechanical Turk und andere Leitinnovationen des vergangenen Jahres informieren.

Gelegentlich wurde auch versucht, zu postulieren, daß nach Mittelalter und Neuzeit (ging offenbar bis 1980) nun das Zeitalter der Attention Economy angebrochen ist. Das war das Thema dieser Konferenz, und die Grundbeobachtungen stimmen sicherlich nach wie vor. Aber ob wir wirklich alle Schmetterlinge sind, die, statt den Nektar der Attention Economy zu trinken, noch wie Raupen denken, wir müßten die grünen Blätter der Markt-/Geld-/Industrie-Wirtschaft verspeisen (Michael H. Goldhaber)?

Spannender (weil konkreter) fand ich den immer wieder durchscheinenden Trend der Alphabetisierung der „Benutzer“ — vom User Generated Content über die Websiteentwicklungsumgebung Ning bis hin zu den von IBM und JotSpot vorgestellten Wiki-basierten Anwendungsentwicklungsumgebungen. Vielleicht wird die nächste Generation in der Schule (des Lebens) nicht nur Word, PowerPoint und Excel gelernt haben, sondern — mittels geeigneter Umgebungen — auch genug programmieren können, um die kleinen und mittleren IT-Probleme des täglichen Lebens selbst anpacken zu können. Man kann ja träumen.

Tags , , , , ,  | 1 comment | 293 trackbacks

7,000,180 U-Boote

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 in  | Tags , ,  | 1 comment | 358 trackbacks

Rails: 1.0

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 in ,  | Tags , , ,  | no comments | 592 trackbacks

Durchbruch für Echtzeit-AJAX: XMLHttpRequest mit verschiedenen Servern

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:

Serverseite

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.

Clientseite

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

Der Durchbruch

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

Ein Durchbruch im doppelten Sinne

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 in  | Tags , , , ,  | 2 comments | 291 trackbacks

Wenn es nicht in Firefox funktioniert, ist es kein AJAX

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 in  | Tags , , , , ,  | no comments | 503 trackbacks

Aus Alt mach Neu mit AJAX: Instant Messaging und Presence

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 in  | Tags , ,  | no comments | 434 trackbacks

S6: Folienpräsentationen mit Echtzeitsynchronisation

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:

  • S5, die Web-Präsentationslösung von Eric Meyer (ja, der bekannte CSS-Guru);
  • etwas AJAX-Code (natürlich unter Benutzung einer AJAX-Bibliothek wie prototype), und
  • 75 Zeilen Ruby als Server für die Synchronisation.

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 :-)

Posted in  | Tags  | 9 comments | 498 trackbacks

X für ein U

Posted by Olaf Bergmann Fri, 14 Oct 2005 23:51:00 GMT

AJAX schwimmt gerade auf einer Hype-Welle, wie wir sie in vielen Bereichen der Informationstechnologie in den letzten Jahren häufig gesehen haben (von verteilten Datenbanken über Mbone-Konferenzen zu DHTML, Web-Services, usw). Bei diesem natürlichen Prozess wird ein Schlagwort gern stellvertretend für eine ganze Klasse von Konzepten, Technologien oder neuen Denkansätzen verwendet. Der Begriff selbst beschreibt dann nicht immer genau das, was damit gemeint ist. So entbrannte im Blog von Simon Willison im April eine längere Diskussion darüber, ob der Begriff AJAX zweckdienlich sei — zwei Monate nach dem Essay von Jesse James Garrett. Matthew Haughey spricht dann auch ziemlich deutlich aus, was technologiezentrierte Entwickler häufig verdrängen: Die Marketing-Abteilung weiß am besten, wie sich Technologie verkaufen läßt — selbst wenn es sich um altbekannte Technologien handelt, die die Entwicklergemeinde für sich neu entdeckt hat.

Was AJAX angeht, zeigt sich gerade das “X” nur als bedingt belastbar. Vielfach setzen AJAX-basierte Anwendungen asynchrone Kommunikation und JavaScript ein, aber es wird weit und breit kein XML verwendet. Der Grund dafür sind die Anforderungen an die Plattformunabhängigkeit: Auch im Jahr 2005 kann XML-Unterstützung nur bei sehr wenigen Browsern vorausgesetzt werden. Mit HTML (nicht XHTML) oder auch einfach zu parsierenden Legacy-Formaten ist man immer auf der sicheren Seite und muß sich nicht in die Abhängigkeit bestimmter Browser-Eigenschaften begeben, die wiederum Feature-Sniffing voraussetzen würden.

Posted in  | Tags ,  | no comments | 434 trackbacks

Stimmen aus dem Nachbarland

Posted by Carsten Bormann Fri, 14 Oct 2005 20:14:00 GMT

An einem Artikel aus dem Online-Auftritt der österreichischen Zeitung „Der Standard“ hat sich eine heiße Diskussion über den Sinn und Unsinn von AJAX entzündet. Hier meine kurze Zusammenfassung der Standpunkte der AJAX-Kritiker:

  • Flash konnte das schon immer

    Ja. Allerdings eben nicht mit dem standardisierten Web zusammen, sondern immer in der schönen bunten Flash-Welt isoliert. Meine Reaktion, wenn ich mich auf einer Site im Flash-Käfig wiederfinde: Ich will meinen Browser wieder haben! Der Versuch, die Flash-Welt mit AJAX unter dem Begriff „Rich Internet Applications“ über einen Kamm zu scheren, demonstriert schon ein wenig den Bedarf, diesen Nachteil durch geeignete Wortschöpfungen zu verschleiern.

    Im AJAX-Buch diskutieren wir aber auch durchaus eine Flash-basierte Alternative zur reinen AJAX-Lehre. Beispielcode dafür, daß sich AJAX und Flash sogar hervorragend vertragen können, findet sich hier, mit einer Demo dazu. Andererseits wird dieser Rückgriff auf eine proprietäre Technologie durch die zunehmende Verbreitung von SVG, z.B. in Firefox und Safari, in Zukunft vielleicht seltener erforderlich sein. Für die Interaktion mit Ton und Video in Webseiten ist Flash allerdings noch Stand der Technik; auch hier hilft AJAX drumherum dabei, eine Web-Anwendung zu behalten.

  • Browser konnten das schon lange, es hieß nur DHTML etc.

    Ja. Allerdings haben wir in den letzten 12 Monaten viel darüber dazugelernt, wie man mit AJAX eigentlich sinnvoll arbeitet. Es gibt jetzt design patterns (Entwurfsmuster), an die vor einem Jahr niemand gedacht hat. Sehr schöne Bibliotheken wie Prototype und Scriptaculous sind entstanden und haben eine erstaunliche Reife entwickelt. Neue Anwendungen, die sich so gänzlich anders anfühlen als das „alte Web“, sprießen wie Pilze aus dem Boden.

    Es lohnt sich auch für ausgefuchste Web-Entwickler, zu verfolgen, was in AJAX-Land passiert.

  • AJAX ist kein Allheilmittel, bringt auch Nachteile, …

    Ja. Vor allem ist eine Überdosierung schädlich (wie damals bei Flash). Auch dazu mehr im Buch.

Und nein, man braucht keine neuen Browser (oder Plugins), man muß (trotz des irreführenden Namens) durchaus nicht mit XML AJAXen, etc. Auch das erklärt natürlich alles das Buch. (Kann es sein, daß ich mich wiederhole?)

Posted in  | Tags ,  | no comments | 764 trackbacks

AJAX-Buch kommt am 14.10.2005

Posted by Carsten Bormann Mon, 10 Oct 2005 20:43:00 GMT

Am 14.10.2005 ist es soweit: Das erste deutschsprachige Buch zum Thema AJAX wird ausgeliefert.

Warum AJAX? Das Web wird sich in den nächsten Monaten und Jahren ändern („Web 2.0“). AJAX spielt eine wichtige Rolle dabei, das Interaktionsdesign vom Hypertext-Paradigma zur Web-basierten Anwendung weiterzuentwickeln.

Warum ein Buch? Es gibt natürlich viel Information im Web. Das gute alte Medium Buch ist aber zum Einarbeiten in neue Themen immer noch schwer zu schlagen.

Warum auf deutsch? Das ist in einer Web-Welt, die fast nur noch auf englisch arbeitet, schon schwerer zu beantworten. Ich selbst arbeite gerne in beiden Sprachen. Für die Lehre (und das ist eben eine meiner Aufgaben) ist die Muttersprache der Lernenden aber immer noch am besten geeignet. Englischsprachige Bücher zu AJAX kommen gerade auf den Markt, warum also nicht ein deutschsprachiges schreiben?

Posted in ,  | Tags , ,  | 2 comments | 3852 trackbacks