RSS shows its age in real-time web (SUP and XMPP to the rescue?)

The real time web is coming at us very quickly, but it exposes major problems in our RSS/Atom infrastructure.

What is the real-time web?

You can get a small taste of that by watching the 5,300+ people I’m watching in Real Time on friendfeed.

The first time I saw the real-time web, I saw it when my tweets showed up on Twitter search and friendfeed within minutes. Sometimes within seconds. Now, imagine a world where everything worked like that. That’s the real-time web.

The problem is that our blogs don’t participate in the real-time web. They publish via RSS. RSS is not real time. RSS only publishes when a service like Google Reader asks for it. It has no way to wave its hand and tell your reader “hey, there’s something new here for you to get.” So, most RSS aggregators just visit on a regular basis, looking every few minutes to see whether something new has shown up.

For blogs that’s just fine. After all, most blogs take a few minutes to a few hours to write and it won’t kill you if you don’t read my words here for 20 minutes or longer.

But there’s a new expectation that we’re having thanks to Twitter. We want everything now in real time. I want to see everything that was published now and respond to it now and I want to have conversations about all that in real time.

This works on Twitter and friendfeed, which were built on real-time principles (er, messaging principles) rather than Web principles.

But when you try to hook the real-time web up to the old creaky RSS web, well, you see that the two aren’t very compatible.

Today I tried to setup an ego feed where I could track stuff that uses my name from around the web in real time. It doesn’t work very well. It’s slow. And, worse, friendfeed can’t tell where the original item came from so it gives it a generic RSS icon. So, it’s not only not real time but it’s ugly as well. I talked more about that with a bunch of people on friendfeed today.

So, what’s the answer?

Well, the geeks are exploring two technologies.

The first is XMPP. This is protocol developed for instant messaging applications but Twitter and friendfeed and others have adopted it. This is why when you Tweet the message shows up in friendfeed so fast.

The second is SUP. This was designed by friendfeed to be more efficient, like RSS. But with the added benefit that the feed provider can raise its hand and say “I have something new for  you.” This makes real-time feeding possible, as developer Jeff Smith demonstrates when he built a system that shoved data into friendfeed in just a microsecond.

The third is GNIP, which is trying to build a service that stands between all sorts of services that are supporting the real-time web.

The problem? Very few services that could help the real-time web evolve are using either of these two protocols.

In fact, I was shown a real-time news service that’ll come out in March that didn’t use either of these protocols. Why? They didn’t even know that a real-time web was evolving on Twitter and FriendFeed and that there are dozens of tools like Twhirl and TweetDeck that are built on top of those too. Which is why I’m writing this post.

If you’re a developer, are you thinking about how to make your feeds real time? Why not?

One reason I can see is that it increases the bandwidth needed, especially if you’re pushing out a lot of data. So, in this harsh economic times developers might be unwilling to spend more resources. But there are some things, like searches, that need real-time results. I’d love to hear what developers are thinking here about balancing the need for low-cost systems with real-time publishing.

More info on SUP and the real-time web:

Paul Bucheit, co-founder of friendfeed, started a whole discussion about it.
OurDoings, a photosharing service, was one of the first services that supported the real-time web on friendfeed and they wrote about their experiences with SUP here.
The friendfeed blog has more info on the release of SUP.
Derek van Vilet made a WordPress plugin for SUP and explains that here.

UPDATE: Mike Taylor says I should have mentioned some XMPP resources in this friendfeed conversation. Here’s the ones he recommended: http://xmpp.org
http://metajack.im/

http://stpeter.im/

http://ralphm.net/blog/

Jonathan Jesse, in same friendfeed thread, added: “Robert: on Leo Laporte’s FLOSS Weekly they covered XMPP with one of the developers and the guy who writes the documentation for Jabber is a great overview of XMPP and more info: http://twit.tv/floss49 ”

Comments

  1. But there’s a new expectation that we’re having thanks to Twitter. We want everything now in real time.

    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?

  2. But there’s a new expectation that we’re having thanks to Twitter. We want everything now in real time.

    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?

  3. As a developer I’m thinking about HTML 5 server-sent events, HTML 5 Web Sockets and of course XMPP. The common theme: standardised, open technologies, developed by open groups, not vendors.

    One reason I can see is that it increases the bandwidth needed, especially if you’re pushing out a lot of data.

    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?

  4. As a developer I’m thinking about HTML 5 server-sent events, HTML 5 Web Sockets and of course XMPP. The common theme: standardised, open technologies, developed by open groups, not vendors.

    One reason I can see is that it increases the bandwidth needed, especially if you’re pushing out a lot of data.

    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?

  5. Addendum: for news I’m with Steven Kaye. The »real-time«-Web is only interesting for live human-to-human-contact, i.e. chatting. Although I’v got this little imp on my shoulder, asking why every damn thing, which worked in the eighties has to be reinvented for the web. Compare IRC and the chatting thingies in new walled gardens, for example.

  6. Addendum: for news I’m with Steven Kaye. The »real-time«-Web is only interesting for live human-to-human-contact, i.e. chatting. Although I’v got this little imp on my shoulder, asking why every damn thing, which worked in the eighties has to be reinvented for the web. Compare IRC and the chatting thingies in new walled gardens, for example.

  7. You should really check what we do at Notifixious (I sent you an email a few weeks ago about it, but I gues it got lost in your bottomless inbox ;p)

    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!

  8. You should really check what we do at Notifixious (I sent you an email a few weeks ago about it, but I gues it got lost in your bottomless inbox ;p)

    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!

  9. Every blog (and website in general) should support a plugin similar to the Jabber-Feed WordPress plugin which allows to publish blog posts with XMPP Pubsub in ATOM format.

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

  10. Every blog (and website in general) should support a plugin similar to the Jabber-Feed WordPress plugin which allows to publish blog posts with XMPP Pubsub in ATOM format.

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

  11. Hi Robert,

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

  12. Hi Robert,

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

  13. thanks for noting the “real-time” web’s criticality. I’m pulling a chapter together for an upcoming O’Reilly book on the very topic. I’m also pouring my heart and soul into Gnip to address the latency issue of which you speak. bottom line is that the web lacks an event driven framework. the standard technologies exist to support event driven activities (XMPP, Web Hooks (HTTP POST)), but they’re rarely used to address this problem at large. Gnip’s trying to address the high-latency problem by providing a protocol agnostic message bus to connect Publishers with Subscribers. ideally folks use Gnip in it’s event-driven form, but it can be polled for those who don’t have event driven architectures.

    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.

  14. thanks for noting the “real-time” web’s criticality. I’m pulling a chapter together for an upcoming O’Reilly book on the very topic. I’m also pouring my heart and soul into Gnip to address the latency issue of which you speak. bottom line is that the web lacks an event driven framework. the standard technologies exist to support event driven activities (XMPP, Web Hooks (HTTP POST)), but they’re rarely used to address this problem at large. Gnip’s trying to address the high-latency problem by providing a protocol agnostic message bus to connect Publishers with Subscribers. ideally folks use Gnip in it’s event-driven form, but it can be polled for those who don’t have event driven architectures.

    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.

  15. Answer from developper: there is no real standard. They are only proposals or custom solutions.

    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)

  16. Answer from developper: there is no real standard. They are only proposals or custom solutions.

    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)

  17. I’m responsible for the SUP implementation on OurDoings, and would like to respond to Stephen Kaye’s valid question about whether real time is desirable for all kinds of information.

    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.

  18. I’m responsible for the SUP implementation on OurDoings, and would like to respond to Stephen Kaye’s valid question about whether real time is desirable for all kinds of information.

    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.

  19. Perhaps I’m an old fart, but I can’t keep track of things in real time. RSS and Email is plenty fast. I don’t need instaneous updates.

  20. Perhaps I’m an old fart, but I can’t keep track of things in real time. RSS and Email is plenty fast. I don’t need instaneous updates.

  21. The “real-time” web is certainly a driving factor for this, but painting it expressly in terms of consumer aggregation apps leads people down all sorts of unhelpful rabbit holes.

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

  22. The “real-time” web is certainly a driving factor for this, but painting it expressly in terms of consumer aggregation apps leads people down all sorts of unhelpful rabbit holes.

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

  23. Eric: excellent point! I’ve seen other services that are doing stuff in real time that aren’t consumer web apps. Which is partially why I’m discussing this here now.

  24. Eric: excellent point! I’ve seen other services that are doing stuff in real time that aren’t consumer web apps. Which is partially why I’m discussing this here now.

  25. I find myself relying on Twitter Search almost as much as Google Search now, especially when it comes to News, rather than just finding Info. There is a gap between when Twitter Search finds things and Google does, and there is room for products that can get users what they want as fast as possible. Being a hard-core user of FriendFeed exposes some of that gap for other pieces, such as how long it takes RSS to hit FeedBurner or Google Reader. That SUP and XMPP are working on the problem is a big boon to the Web’s future.

  26. I find myself relying on Twitter Search almost as much as Google Search now, especially when it comes to News, rather than just finding Info. There is a gap between when Twitter Search finds things and Google does, and there is room for products that can get users what they want as fast as possible. Being a hard-core user of FriendFeed exposes some of that gap for other pieces, such as how long it takes RSS to hit FeedBurner or Google Reader. That SUP and XMPP are working on the problem is a big boon to the Web’s future.

  27. When mobile phones became popular we were obsessed with being ‘always on’ until we realised that we didn’t want to be always on. This idea is the same. Everyone will go wild over the idea of having quicker access to information until they realise that perhaps they didn’t want it after all.

    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.

  28. When mobile phones became popular we were obsessed with being ‘always on’ until we realised that we didn’t want to be always on. This idea is the same. Everyone will go wild over the idea of having quicker access to information until they realise that perhaps they didn’t want it after all.

    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.

  29. “We want everything now in real time.”

    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.

  30. “We want everything now in real time.”

    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.

  31. Robert, are you the “The six millions dollar man” ? I think you are, since I can’t keep track of everything in real time and I bet most people out there think the same. It can be useful for people whose main job is writing news, not for “normal people”. For me RSS is real time enough :-)

  32. Robert, are you the “The six millions dollar man” ? I think you are, since I can’t keep track of everything in real time and I bet most people out there think the same. It can be useful for people whose main job is writing news, not for “normal people”. For me RSS is real time enough :-)

  33. Robert, I just set up an ego demo within our TwitterProbe desktop app. What am I missing?

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

  34. Robert, I just set up an ego demo within our TwitterProbe desktop app. What am I missing?

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

  35. Developers interested in reliable, scalable, real-time messaging should investigate TIBCO’s Messaging solutions, http://www.tibco.com/software/messaging/. They literally have the patent for reliable publish and subscribe protocols. Take a look at JMS, SmartSockets, and the grandaddy of all pub/sub, TIBCO Rendezvous software.

  36. Developers interested in reliable, scalable, real-time messaging should investigate TIBCO’s Messaging solutions, http://www.tibco.com/software/messaging/. They literally have the patent for reliable publish and subscribe protocols. Take a look at JMS, SmartSockets, and the grandaddy of all pub/sub, TIBCO Rendezvous software.

  37. As a follow-up to the last comment, you could also check out IBM’s messaging solutions – WebSphere MQ, MQTT, MQLLM etc. which all do pub/sub messaging.

  38. As a follow-up to the last comment, you could also check out IBM’s messaging solutions – WebSphere MQ, MQTT, MQLLM etc. which all do pub/sub messaging.

  39. Most people don’t read 5000 feeds. Most people have jobs where they cannot respond real-time to the latest happenings in the blogosphere. I think you are looking for a solution to a problem that exists for very few people.

  40. Most people don’t read 5000 feeds. Most people have jobs where they cannot respond real-time to the latest happenings in the blogosphere. I think you are looking for a solution to a problem that exists for very few people.

  41. @Randy: I think you miss one point. You are right for human. But today there is no *standard* mechanism for a Machine-to-Machine notification on the web that has emerged (Let’s forget languages’ or editors’ specific solutions that are worth only in their microcosm).

    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.

  42. @Randy: I think you miss one point. You are right for human. But today there is no *standard* mechanism for a Machine-to-Machine notification on the web that has emerged (Let’s forget languages’ or editors’ specific solutions that are worth only in their microcosm).

    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.

  43. Robert, as one might imagine, this subject remains of profound interest in furthering our ‘LAFD Everywhere’ initiative. While we have no plans of leaving our popular Web2.0 properties such as Twitter @LAFD , we’re really hoping to experiment and further some of these real-time tools in the near future. Hope to see you at CES. Be safe.

    Brian Humphrey
    Los Angeles Fire Department

  44. Robert, as one might imagine, this subject remains of profound interest in furthering our ‘LAFD Everywhere’ initiative. While we have no plans of leaving our popular Web2.0 properties such as Twitter @LAFD , we’re really hoping to experiment and further some of these real-time tools in the near future. Hope to see you at CES. Be safe.

    Brian Humphrey
    Los Angeles Fire Department

  45. [...] Twitter is the new Google Reader. The world is moving fast and you’re not catching up! Ask Robert Scoble, your friendly neighbor internet know-it-all. He says RSS shows its age. Q.E.D. But there’s a new [...]

  46. [...] Second, on January 17, 2009, U.S. Airways Flight 1549 went down in the Hudson River. Everyone survived thanks to an amazing pilot. And, all were saved thanks to the quick thinking of the flight crew and help from the people in the surrounding area. It was an amazing story made even more amazing by the fact that just moments after the plane went down, the news was out…on Twitter. Pictures flew on to sites like TwitPic and those people who were on Twitter at the time, again, became part of the action. It was this event that did it for me. I couldn’t miss another big event because I wasn’t participating the the Realtime Web. [...]

  47. twitter both ways specifications…

    twitter development These are the different steps to improve the twittermixin integration and have a viral effect via twitter: Better parser Post back to twitter Register from twitter Update twittter’s settings page in mixin Here is a schema of the……

  48. realtime for when a daytrader i'd like to follow enters his trades on his blog – i can't wait 20min to find out what i should have bought 20min ago – i need it realtime as soon as he enters his trades on his blog – he's not tweeting so i can't do google reader and this is what i need – realtime.. so there are applications out there for realtime other than people just reading news or other info that can wait 20min