[ruby-de] feedparser, JSONFeed und FEED.TXT (war: planet.ruby-portal.de offline)

Marvin Gülker m-guelker at phoenixmail.de
Fr Jun 9 02:43:30 JST 2017


Hi Gerald,

On Thu, Jun 08, 2017 at 05:32:59PM +0200, Gerald Bauer wrote:
>     Da bin ich wohl gescheitert ;-)  Bin immer ein Freund von
> Einfachheit und Minimalismus, daher verstehe ich natürlich Deine
> Argumentation.

Und ich bin immer ein Freund von Argumentationen. Daher an dieser Stelle
ausdrücklich dank dir dafür, das Thema auf den Tisch gebracht zu
haben. Es sind diese Diskussionen, die eine Liste wie diese erst
wirklich interessant machen.

> Dran bleiben an Uranus - großartige Alternative zu
> Pluto [1] ;-)  übrigens Pluto jetzt neu mit Doku [2] und Quick Starter
> Paket [3]!

Pluto ist mindestens ebenso großartig. Man erkennt, wie Gerald und ich
unterschiedliche Ansätze in der Implementation verfolgen, von daher
sollte jeder das auswählen, was seinen Anforderungen am besten
entspricht. Und es tut gut zu sehen, dass Pluto jetzt auch dokumentiert
ist -- die fehlende Dokumentation war ja maßgeblicher Antrieb für mich,
Uranus zu schreiben.

> Bei Interesse - zu meiner Argumentation zu JSON Feed, HTML mit
> Microformats (h-feed/h-entry), Feed.TXT und Freunde siehe
> Vortragsnotizen [4] (in Englisch) vom heutigen (Do 8. Juni) Vienna.rb
> / Wien.rb Vortrag.

Ich habe mir das mal durchgelesen. Gäbe es einen Standard für
Syndication noch nicht, dann würde ich natürlich auch zu einem
einfacheren Format wie JSON anstatt XML greifen. Das Problem liegt in
den vorhandenen Anwendungen. feedparser ist ein toller Gem, aber nicht
jeder Feedreader ist in Ruby geschrieben; mein newsbeuter (C++-Software)
versteht JSONFeed nicht. Auf Serverseite mag es wohl wohl ein
Wordpress-Plugin geben, allerdings glaube ich nicht, dass ein typischer
Webseitenbetreiber aus bloßer Freude daran, Entwicklern neuer Feedreader
das Leben leichter zu machen, ein relativ unbekanntes Plugin
installieren wird.

Deine Aussage, dass insbesondere RSS auch und gerade wegen der
verschiedenen Versionen ein etwas unübersichtliches Format sei, ist zwar
inhaltlich richtig, kann aber nicht dazu dienen, ein Alternativformat zu
propagieren, weil aus diesem Grunde bereits das Atom-Format entstanden
ist. Zitat Wikipedia[1]:

> Atom entstand aus dem Bedürfnis heraus, die Vorteile der
> unterschiedlichen RSS-Formate in einem neuen Format zusammenzufassen
> und um neue Elemente zu ergänzen. Dabei haben die Entwickler – in
> überwiegender Mehrzahl Blogger – ASF auch so gestaltet, um den
> speziellen Bedürfnissen von Blogs und Nachrichtenseiten gerecht zu
> werden.

Noch deutlicher die englische Wikipedia[2]:

> When Atom emerged as a format intended to rival or replace RSS, CNET
> described the motivation of its creators as follows: "Winer's
> opponents are seeking a new format that would clarify RSS ambiguities,
> consolidate its multiple versions, expand its capabilities, and fall
> under the auspices of a traditional standards organization."

Demnach müsste JSONFeed schon über Atom hinausgehende Vorteile
aufweisen, um signifikant adaptiert zu werden. Dazu genügt m.E. die
Einkleidung in JSON statt XML nicht. Auch fehlt es an der Einreichung
zur Standardisierung etwa bei der IETF, weshalb tatsächlich also wieder
zu Zuständen zurückgekehrt wird, wie sie für die Entwicklung des
RSS-Formats charakteristisch waren.

> Rules for Standard Makers - Evolve or Die ;-) - Break Things - Many
> Worlds Possible (Cont.)

Den Standards-XKCD hast du ja schon selbst zitiert. Da selbst RSS 1.0
aus dem Jahre 2000 noch immer gelegentlich anzutreffen ist, ist von einer
marktübergreifenden Durchsetzung eines anderen, neuen Formats nicht
auszugehen. Bestenfalls haben wir dann drei konkurrierende Standards
statt zwei (plus die verschiedenen RSS-Versionen).

jsonfeed.org gibt folgendes an[3]:

> Our hope is that, because of the lightness of JSON and simplicity of the
> JSON Feed format, developers will be more attracted to developing for
> the open web.

Die RSS- und Atom-Formate sind keine proprietären Formate und damit
ebenso „open web“ wie JSONFeed. Der implizite Vorwurf an RSS- und
Atom-Implementierer, sie seien gegen ein „open web“, entbehrt damit der
Grundlage und ist schlicht falsch.

> Multiple attachments.

*Das* ist ein Fortschritt. Insbesondere, weil Atom bekanntlich keine
Anhänge unterstützt und RSS nur einen. Aber ob der Bedarf an diesem
Feature groß genug ist, um zur Migration zu führen, bezweifle ich.

> Modern needs such as avatar images, feed icons and favicons, and
> banner and featured images. Feed readers should not have to search and
> scrape to guess at these things.

Auch das ist eine tolle Idee, nur werden Feedreader das trotzdem machen
müssen, weil sie nicht einfach aufhören können, RSS und Atom zu
unterstützen. Ergo: Mehraufwand für die Entwickler.

> A simple way to add extensions.

Siehe RFC 4287, Abschnitt 6[4].

Zum Schluss noch eine Anmerkung zum JSONFeed-Format als solchem: Es
fehlt eine Möglichkeit, denselben Inhalt (ein Item) in mehreren Sprachen
zur Verfügung zu stellen. Das ist in Atom mit xml:lang-Attribut
möglich.

Viele Grüße
Marvin

[1]: https://de.wikipedia.org/wiki/Atom_(Format)
[2]: https://en.wikipedia.org/wiki/Atom_(standard)#Atom_compared_to_RSS_2.0
[3]: https://jsonfeed.org/version/1
[4]: https://tools.ietf.org/html/rfc4287#section-6

> 
>   Gruss aus Wien.
> 
> 
> [1] https://github.com/feedreader/pluto
> [2] http://feedreader.github.io
> [3] https://github.com/feedreader/pluto.starter
> [4] https://github.com/geraldb/talks/blob/master/webfeeds2.md

-- 
ruby-de-Admin

Blog: https://www.guelkerdev.de
PGP/GPG ID: F1D8799FBCC8BC4F


Mehr Informationen über die Mailingliste ruby-de