ATOM - Wer braucht das bitte?

Während ich hier an einem Einführungstext zu ATOM sitze stelle ich mir nicht mehr nur die Frage „Wozu brauch ich ATOM eigentlichen?“, sondern vor allem: „Wozu brauche ich einen ATOM-Feed, wo doch kein Reader es unterstützt“.
Mal ehrlich: So einen ATOM-Feed ist dank Templates bei keinem vernünftigen Blog-Tool wie sunlog, g!zmo oder MovableType ein Problem. Aber warum sollte ich mir die Mühe machen, wo es noch kein Reader versteht … Ja. Ich gebe mir die Antwort selbst (danke): Damit die Reader es bald können.
Aber: Macht es für den Leser einen Unterschied ob er einen RSS 2.0-Feed oder einen ATOM-Feed liest? Kaum. Deshalb hätte man weniger sinnloses Gefassel in die Namensdiskussion stecken und es RSS 3.0 nennen sollen.
Und wann wird ATOM sich durchsetzen? In 2 Jahren? 3? Bedenken wir, dass gerade Medienhäuser RSS entdecken und endlich nutzen … Oder sollten wir das Land jetzt mit einer „Nutzt ATOM! ATOM ist geil, RSS uncool“-Kampagne überziehen?!

10 Kommentare

  1. Um den Namen gab es ziemliche Diskussionen; das ganze sollte ursprünglich Echo heissen. RSS 3.0 wäre vielleicht für Aussenstehende einfacher gewesen, aber ich bin mir nicht sicher, ob das mit Dave Winer auf die Dauer gut gegangen wäre.

    Der Vorteil an Atom ist für mich, dass es nicht einfach nur Syndication macht, sondern ein ganzes API definitiert, über das man zum Beispiel auch Artikel ins Weblog stellen oder löschen kann. Und es ist scheint mir recht ordentlich zu werden, allerdings auch recht komplex.
    —–

  2. Wort hoch, Kollege. Aber man soll den Tag ja nicht vor dem Abend loben. Vielleicht sitzen wir ja in 2, 3 Jahren da und fragen: „RSS? Welche Partei war das doch gleich?“

  3. Georg: Was fehlt Dir denn im REST-Ansatz? Durch Übernahme des HTTP-Modells der Verben und der zu manipulierenden Objekte sollten doch alle Anwendungsszenarios einer weblogartigen Seite abgedeckt sein.

    Nebenbei: So wie ich das mitgekriegt habe, ist Atom letztendlich nur aus der Geschichte mit den funky feeds entstanden. Auch eine nette Fußnote der Geschichte. 😉

  4. Ich denke es eher aus einer höheren Ebene: Einen Atom-Feed anzubieten ist einfach und wenn niemand einen anbieten würde, würde niemand es für nötig halten, tools dafür zu entwickeln. So war das mit Trackback auch. Und ich denke, dass es weniger als 3 Jahre braucht, um das zu etablieren.

  5. > ob das mit Dave Winer auf die Dauer gut gegangen wäre

    he? das bedeutet wenn es ATOM ist lässt Dave Winner endlich seine Finger davon?

    Dann will ich es sofort auch haben.

  6. REST ist eben _nur_ für das sinnvoll anwendbar, was sich mit diesen einfachen Verben GET/POST/PUT/DELETE abbilden lässt. Ist ähnlich wie mit SQL: das Konzept ist ganz niedlich, aber in der Realität dann doch zu theoretisch. Niemand kommt mit den reinen select/insert/update/delete aus, die Leute wollen Views, Trigger, referentielle Integrität etc. Das gleiche Problem gibts bei REST. Es ist eben nicht alles nur mit den vier Verben abbildbar – und sobald man dann damit mehr macht, wirds wild: POST oder ähnliches mit wilden Parameterorgien sind oft die Folge. Die Welt ist grösser als nur Weblogs – und Atom will ja genau diese grössere Welt bedienen. Was ist zum Beispiel mit Wikis? Bei denen ist nicht nur ein einfaches GET wichtig, mit dem man den Source bekommt, sondern auch diverse andere Informationen (Versionslisten, alte Versionen, Linkstruktur etc.) interessant. Klar, GET mit Parametern. Und schon ist REST nicht mehr so schön einfach wie es mal war, weil man plötzlich mit URL-Quoting und ähnlichem Mist zu tun hat.

    Letzten Endes zeigt REST für mich zwei Sachen:

    – es ist keine gute Idee ein theoretisches Modell zu sehr in den Mittelpunkt zu stellen, jedenfalls nicht wenn man keine Erweiterbarkeit einplant (guck dir mal WebDAV an um zu sehen was ich mit Erweiterungen meine 🙂 )

    – es ist eine _saublöde_ Idee eine API-Struktur an der Grundlage eines _Protokolles_ aufzubauen. Es gibt _sehr_ gute Gründe warum APIs üblicherweise höhere Schichten der Abstraktion bieten als die eigentlichen Protokolle. Diese „Back to the basics“ Bewegungen, die immer wieder in der Programmierung auftauchen, sind ja ganz niedlich. Aber letztendlich nicht wirklich ernstzunehmen. Höhere Abstraktionen (wie z.B. XML-RPC oder SOAP sie bieten) haben ihren Grund. Die Vertreter von REST negieren einfach all die Erfahrungen, die zu XML-RPC und SOAP geführt haben, und meinen all die Probleme nochmal durchleben zu wollen.

    REST ist ein typischer Fall von „Theoretiker treffen Hobbyprogrammierer“. Die Theoretiker sind begeistert, weils ein so schön sauberes Konzept ist. Die Hobbyprogrammierer sind begeistert, weil es so schön simpel zu implementieren ist. Die professionellen Programmierer ärgern sich (spätestens wenn der Weblogbereich verlassen wird und echtes Content Management mit angebunden werden soll wirds übel), weil dieses API so gut wie keine Arbeit abnimmt und eigentlich nur eine Transportspezifikation ist. Im Weblogbereich ist das unproblematisch – selbst in den betroffenen Firmen sitzen nur Hobbyprogrammierer …

    Über das Authorisierungssystem von Atom lasse ich mich besser garnicht erst aus. Es gibt _keinen_ Grund sowas selber zu erfinden und nicht einfach auf etablierte Methoden zurückzugreifen. Die vorgetragenen Argumente sind einfach hirnrissig. Aber das ist ja weniger ein Problem von REST (das hätte ja diverse Authorisierungssysteme zur Verfügung), sondern ein Problem von Atom.

  7. Atom konnte nicht RSS 3.0 heissen, weil es das schon gibt. Ist allerdings kein XML-basiertes Format, und ist wohl auch eher als Joke entstanden. Trotzdem gibts halt RSS 3.0.

    Zusätzlich hätte Dave Winer gegen RSS was gehabt, da er zu dem Zeitpunkt noch die Spec alleine kontrolliert hat (im Prinzip kontrolliert er die immer noch, die Übertragung an Berkman war eher Augenwischerei).

    Die Finger davon lassen (bzw. aufzuhören daran rumzunörgeln) wird er sicherlich nicht, egal wie es heisst. 🙂

    Warum man Atom braucht? RSS ist in vielen Punkten unpräzise definiert. Sieht Dave Winer zwar anders, aber letztendlich ist es so – RSS hat keine formale Spec, sondern eine verbale. Das führt _immer_ zu Fehlinterpretationen. Auch sind einige Felder in RSS multipler Verwendung zugeführt worden: GUID kann ein Permalink sein oder nicht, Link kann der Link auf den Artikel sein oder der externe Link. Desweiteren gibt es Probleme damit, was in Textfeldern sein darf und ob es encodiert ist oder nicht etc. Atom löst diese Probleme auf jeden Fall.

    Um es mal anders zu sagen: aus RSS würde nie ein IETF-RFC werden können, aus Atom kann es einer werden. Das ist ein klarer Vorteil. Das meiste andere hingegen was als angeblicher Vorteil propagiert wird ist Blabla und dient eher der Ego-Masturbation der Proponenten 😉

    Das API finde ich persönlich nicht so doll, da ich kein REST-Fan bin. Ich finde REST ist viel zu low-level und viel zu weit weg von echten APIs, wie man sie in der Programmierung gewohnt ist. Es ists eine Primitivschnittstelle, die halt nur mit begrenztem Wortschatz aufwartet und dadurch auch nur begrenzte Möglichkeiten bieten kann. Andererseits ist sie so primitiv, das sie leicht zu implementieren ist, von daher stört sie mich auch nicht gross.

    Im Moment sehe ich Atom aber immer noch eher als netzpsychologisches Experiment. Viel interessanter als die Spec sind die recht absurden Verhaltensweisen der Proponenten …

Schreibe einen Kommentar zu amano.ncr Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert