friendfeed arbeitet an effizienterem Protokoll für siteübergreifenden Austausch von Updates

Interessant. Die diese Woche veröffentlichten Neuerungen sind nur ein Teil dessen, was Friendfeed aktuell in der Hinterhand hat. Das hier könnte weit größer sein. Man arbeitet an einem neuen, schlanken Protokoll für einen ressourcenschonenderen (und noch realtimigeren) Austausch von Updates zwischen Sites:

The entrepreneur [Paul Buchheit] says that FriendFeed’s Simple Update Protocol, which the company expects to roll out in September, will allow the service to process updates from social networks and blogging sites more quickly than what’s possible using current Really Simple Syndication technology. SUP, which is being developed by Buchheit and fellow engineer Gary Burd, will allow FriendFeed to query Web sites to determine which feeds have been updated since the last poll and then download only those that have been modified.

 

„FriendFeed downloads millions of RSS and Atom feeds every hour,“ Buchheit explains. „That takes up a lot of resources on our end and on the other end. SUP makes it much more efficient and lets us check much more frequently, like every minute or every couple of seconds, instead of every half hour.“

SUP – Simple Update Protocol. Klingt gut.

 

friendfeeds aktuelles Problem: Ich veröffentliche 14 Uhr einen Blogartikel über xy, 14:05 Uhr twittere ich, dass ich gerade über xy geschrieben habe. Während friendfeed nun zwar den Tweet quasi sofort – also in Realtime – einspeist (weil man an der XMPP-Firehose von Twitter hängt), kann es passieren, dass der Blogartikel erst eine viertel bis halbe Stunde später in das friendfeed-System einläuft. Irgendwann fällt das jedem User auf. Für friendfeed, dass mit seinen Kommentaren Teil des Real-Time-Webs ist, eine unschöne Sache. Der Grund dafür liegt bei RSS und Atom. Um Feeds in Realtime einzuspeisen, müsste friendfeed die Server, auf denen zum Beispiel die Blogs liegen, im Sekunden- oder Minutentakt abfragen. In der Regel wird sowas als Attacke gewertet.

Ohne eine zugrunde liegende technische Lösung rennt friendfeed hier gegen eine Wand mit seinem Konzept. Scheint, man arbeitet an einer Lösung.

EXCLUSIVE: FriendFeed readying RSS accelerator (Tech Confidential – Behind The Money Blog)

Update: Siehe auch Posting auf dem friendfeed-Blog:

FriendFeed Blog: Simple Update Protocol: Fetch updates from feeds faster

SUP (Simple Update Protocol) is a simple and compact „ping feed“ that web services can produce in order to alert the consumers of their feeds when a feed has been updated. This reduces update latency and improves efficiency by eliminating the need for frequent polling.[..]

 

SUP is designed to be especially easy for feed publishers to create. It’s not ideal for small feed consumers because they will only be interested in a tiny fraction of the updates. However, intermediate services such as Gnip or others could easily consume a SUP feed and convert it into a subscribe/push model using XMPP or HTTP callbacks.

 

Man findet mich auf friendfeed hier.

(via, logisch, friendfeed)

About Marcel Weiß

Marcel Weiß, Jahrgang 1979, ist Gründer und Betreiber von neunetz.com.
Er ist Diplom-Kaufmann, lebt in Berlin und ist seit 2007 als Analyst der Internetwirtschaft aktiv. Er arbeitet als (Senior) Strategy Analyst bei Exciting Commerce, schreibt für verschiedene Publikationen, unterrichtet als Gastdozent an der Popakademie Mannheim und hält Vorträge zu Themen der digitalen Wirtschaft. Mehr zum Autor.
Marcel Weiß auf Twitter und auf Facebook abonnieren. (Mehr)

  • FFD

    Die Problematik liegt daran, daß die andere Seite (also die Quellen wie Facebook, Flickr, Blogs etc) ebenfalls SUP implementieren müssen. Warum sollten sie das tun? Um Friendfeed zu unterstützen? Da wird die Motivation nicht so gewaltig sein.

    Auch, wie im Friendfeed-Blog beschrieben, nützt SUP nur zur effizienten Abfrage von großen Aggregatoren. Das Prinzip ist ja statt vielen Einzelabfragen eine Vorabfrage zu machen. Für einzelne Blogs hilft das wenig bis nichts.

  • Stimmt, mein Beispiel mit blogs war ein schlechtes Beispiel. Es könnte aber zum Beispiel für feedburner interessant sein (wobei dort der Realtime-Flaschenhals zwischen feedburner und blog liegt und nicht (nur) zwischen feedburner und den feedkonsumenten).

    Warum andere Dienste SUP implementieren sollten: Es ist ein offenes Protokoll, das auch von anderen Feedkonsumern als friendfeed eingesetzt werden kann und dann Ressourcen auf beiden Seiten schont. Hinter den Kulissen gab es wohl vor kurzem ein wenig Knurren, weil friendfeed bei flickr viel Traffic verursacht. Ist natürlich ein Henne-Ei-Problem, aber da es von friendfeed und keinem kleinen, obskuren Dienst kommt, sieht die Sache mit SUP relativ gut aus, finde ich.

  • huuuu spannend. leider keine zeit zum lesen gerade :( gebookmarkt und fürs WE aufgehoben.

  • FFD

    ok, Feedburner und Flickr machen Sinn!