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

70 thoughts on “RSS shows its age in real-time web (SUP and XMPP to the rescue?)”

1. Pingback: Top 10 Features of the (as yet undiscovered) Perfect Real-Time Web Tool | RobClock | Kicking Around the Web

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?

   LikeLike

3. 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?

   LikeLike

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?

   LikeLike

5. 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?

   LikeLike

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.

   LikeLike

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

   LikeLike

8. Have you forgotten about XML-RPC Ping?

   http://codex.wordpress.org/Update_Services

   LikeLike

9. Have you forgotten about XML-RPC Ping?

   http://codex.wordpress.org/Update_Services

   LikeLike

10. Pingback: Ben Barren - Confessions of a Mad Man » a post RSS monday.

11. 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!

    LikeLike

12. 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!

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    no, we don’t… 🙂

    LikeLike

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

    no, we don’t… 🙂

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

27. Pingback: The danger of ‘right now’ news

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

32. Pingback: improvement through health 2.0

33. XMLRPC Ping is the established standard for distributing website updates. What does SUP or XMPP buy me over those?

    LikeLike

34. XMLRPC Ping is the established standard for distributing website updates. What does SUP or XMPP buy me over those?

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

39. Great post Robert!

    One more good resource for those wondering about SUP is the SUP FAQ: http://code.google.com/p/simpleupdateprotocol/wiki/faq . 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).

    LikeLike

40. Great post Robert!

    One more good resource for those wondering about SUP is the SUP FAQ: http://code.google.com/p/simpleupdateprotocol/wiki/faq . 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).

    LikeLike

41. “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.

    LikeLike

42. “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.

    LikeLike

43. 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 🙂

    LikeLike

44. 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 🙂

    LikeLike

45. Pingback: bluelectric.org » RSS ist nicht Echtzeit

46. prolificprogrammer asks the right question. why doessn’t friendfeed sup standard pings for feeds, and scoble askthem why no opml export?

    http://www.weblogs.com/api.html

    LikeLike

47. prolificprogrammer asks the right question. why doessn’t friendfeed sup standard pings for feeds, and scoble askthem why no opml export?

    http://www.weblogs.com/api.html

    LikeLike

48. 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 🙂

    LikeLike

49. 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 🙂

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

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

    LikeLike

56. @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.

    LikeLike

57. @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.

    LikeLike

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

    LikeLike

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

    LikeLike

60. Pingback: Welcome to The “World Live Web” | LucaFiligheddu.com
61. Pingback: Zef.me › Real-Time Web
62. Pingback: Welcome to The “World Live Web” | Telecom Update
63. Pingback: Twitter or Leave it « itechmo
64. Pingback: The Velocity of Time | Save the Papers
65. Pingback: Is It Time to Let FeedBurner Burn? | Chris Baskind
66. Pingback: New protocols to deal with the real time web « LinksAndThoughts
67. Pingback: Confluence: Client: Mixin

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

    LikeLike

69. Damn

    LikeLike

70. Damn

    LikeLike

Comments are closed.