-
Website
http://www.scobleizer.com/ -
Original page
http://scobleizer.com/2008/12/21/rss-shows-its-age-in-real-time-web-sup-and-xmpp-to-the-rescue/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
I'd question whether this is a necessary expectation, or even a desirable one. We already have proliferation of non-stories in order to fill the news cycle and rushing to chase stories without fact-checking thanks to cable news - why is this something to be encouraged?
Huh? Polling a feed every n minutes, getting a HTTP response or the full feed just to realise that there's nothing new ist better?
http://codex.wordpress.org/Update_Services
We are building a notification platform where we hope to be able to build realtime notifications when a website that you care about has new content (blogs, but also job searches : see our mashup with Simplyhired, or any website).
How do we do this? First, and that's probably where we need more work : we're parsing feeds (a lot of them, very often, which currently leads to a 30min "delay", but we're working on makiing this shorter)
Then, we've got APIs to that anybody can "ping" us which makes it even faster!
Finally, we're using what's available out there for real-time: firehoses (XMPP/PubSub: Identica, Seesmic... or AtomStream: all 6A blogs).
Feel free to check http://notifixio.us and let me know what you think!
There's no client yet, but they might come very soon.
And to make XMPP Pubsub feeds discoverable, blogs should include in their headers a rel link element following XEP-0240 like :
link rel="xmpp.feed" href="xmpp:pubsub.mediamatic.nl?;node=generic/a7fd3c6a-513c-4de1-9b8d-6376e0d24150" title="XMPP updates for this item" (e.g. Ctrl+U on this page).
Regarding bandwidth usage and push-based delivery system, it's theoretically possible to significantly reduce traffic by making nodes subscribe to other nodes (a.k.a Pubsub chaining), which means that one message will be sent from a server to another and then dispatched to resources of the recepient server. But there's still a complete ecosytem to build and organize.
And I don't think it's about the "real-time web" but mostly about the "real-time Internet".
Maybe a few points needs to be clarified:
1. RSS/atom is only a file specification (Not an process specification).
2. RSS has a "TTL" (Time To Live) value that lets the developper knows when he has to refresh the cache. So the TTL can be long on blogs and short on some other application. The developper could say: "Hey, I update the RSS every minute, so grab it every minute".
3. There is no real update mecanism standardized for RSS files. Only thing which is sure (by practice) is that the RSS file is *usually* retrieved using HTTP or HTTPs (and not FTP, pear-to-pear, etc.).
4. Do not forget that HTTP is a "disconnected" protocol. You cannot do "real" real time.
The only thing you can do is have some tricks to approch real time: An application (A) that provides an RSS could "ping" the application (B) who needs it when an update is done (So there would not be unnecessary requests). Problem: the application (A) must know that application (B) exists (The ping and the registration mech. are not standardized).
a couple of notes:
SUP - it does a fine job optimizing polling. surprised folks didn't pull it together several years ago, but I guess it just took time for "the problem" (high latency) to really come to the fore. if we're going to continue to ignore the need for an event based model (again, XMPP or web hooks/HTTP POST), everyone needs to adopt SUP; it turns a horrible situation into just a bad one.
XMPP - neat on paper. still too immature for widespread practical use at scale (beyond IM). Cisco will fix this over the next 5 years or so as the baseline protocol gets burned into routers.
So it is hard to bet on the right horse... And the risk is high!
Same issue as the login system (MySpacID? Facebook Connect? Google Connect?). When you have a complexe application you cannot have the solution (a login solution) implemented X times:
- Ressources (developpers) are precious
- you have to develop new functions for your application
- you do not want to add unwanted complexity to handle afterwards.
You just wait a real standard or you wait the end of the big dogs' fight and implement the winning solution that fits your needs (Remember BR / HDDVD, SOAP - REST,... ? ;) )
(Sorry for my poor English)
no, we don't... :)
I was asking myself the same question while implementing SUP. OurDoings was originally designed for people who had a hard time keeping up with their photo sharing. You can upload photos in huge numbers and it organizes them for you by date, in a blog-like format. If you've waited for months to share them, who cares how fast they go out to your social network via FriendFeed?
It actually does help psychologically. The closer a reward is to an action, the better it reinforces it. When your social network likes or comments on what you've shared, that's a reward. The sooner that reward happens, the better it reinforces the action of sharing. And for busy people (e.g. parents) who might otherwise disappear from their friends' lives, sharing needs to be encouraged.
The real issue here is about machine-to-machine transfer of personal data so that you can enable services B - Z can all take advantage of the data you or your contacts have given service A.
While the social sites have been the first to present use cases for real-time data distribution, it's e-commerce and information services who will create widespread consumer value out of shared data. Once data is truly in the cloud, everyone (with proper authentication, of course) will be able to leverage the intention data that you create across various services.
Frankly, all the social media stuff can be a bit overwhelming. What I'm really looking for is smarter applications that understand me better and that starts by putting my data in the cloud. Otherwise, it's just the search engines and primary social networks fighting out who controls your data and let's you have access to it from time to time (an under their strict terms of use).
The speed at which we currently receive information is suitable for me and it will remain so until there is a good reason for that to change. Actually, that's not true. Some days there is simply too much information and not enough time to consume it. We all have lives after all.
One more good resource for those wondering about SUP is the SUP FAQ: http://code.google.com/p/simpleupdateprotocol/w... . It answers several of the questions people here are asking, such as Prolific Programmer's question about SUP vs XMLRPC Ping. If anyone has other question of SUP, feel free to email me (paul at friendfeed).
Do we? You may, the average Joe Bloggs probably doesn't. We need the *option* to have things in that way. For me, event driven information (conference, TV event, sports) would be useful real time - if I had the real time to watch it unfold. The rest, happy to have it via RSS to the reader. It stays there, ready for me to look at when I need it.
The biggest advantage of a reader over something like friendfeed (which can easily do the same information) is that a reader allows me to classify things, keep things unread, read them in the order I want to. FF is mainly a 'river' of news. it's less easy to cheery pick what you want now, come back to the rest later.
The conversation aspect around FF is one of the best attributes, but as you're the only person I see with the traction to hold a conversation there, the app just spends most of it's time being an aggregator to catch up with things on occasion. I'm sure that will change.
http://www.weblogs.com/api.html
- I created Feed entries on your four ego searches, polling every 1 min
- all entries appear within a window titled "MyEgoHose"
- I can also create a new window titled "MyEgoFilter1{...#}" with filtered criteria
- I can set Alarms
- an alarm can send each entry to SMS
- an alarm can send each entry to email
- an alarm can retweet each entry
- I can also enter all my other 400+ RSS feeds with full filtering / alarm settings
- With Twitter's new Hosebird, I can have an instant twitter feed, with full Event filtering / alarm settings
- If FriendFeed provides a simplified feed of FFRT, I can filter that too. XMPP complexity sucks. We're simply not that smart.
- I can query, order, report, graph and export any of my data.
- I can access all filtered Events via a webpage, or my iPhone.
- Open source would be an option.
So I'm sitting here pretending to be you Robert, receiving sms's each time your ego is stroked :) watching millions of tweets go by, or only tweets from my friends, or tweets being tracked within an Event. Pretty simple.
I have your FriendFeed Realtime window open, and it's fun but it's not healthy. Whoa, a news source just filled up the entire timeline bumping everyone else off. That was fun! How do I find the entries that just disappeared?
Obviously, I'm missing something?
M :)
A standard mechanism using RSS on http would be the first step to new kinds of applications that could use all this data and turn in into information.
Brian Humphrey
Los Angeles Fire Department