Slashdot Mirror

i googled my /. username and found more than one site duping /. articles:

http://jetlib.com/news/tag/earth/page/20/
http://pubsub.com/Puck-Daddy-Mini-Doc-Talking-2010-NHL-Draft-and-dream-cars-with-Taylor-Hall-Tyler-Seguin-and-Cam-Fowler-Sunny-the-Sun-n-cpTsvVWHWnSS

plus a lot of other stuff i knew would be found if anyone did that. so i don't feel betrayed at all.

... it's the network of interlinking blogs (via trackback/pingback) that carry on an ongoing conversation that is the real power of the blogs. Along with RSS and Atom, which aside from just letting you read a bunch of blogs through a single interface also let sites like Technorati provide a nearly real-time search of the "live" internet, blogs and the related technologies that have sprung up around them are really creating a new paradigm of information sharing. Google lets you search the static web, but Technorati (and PubSub, and Google Blogsearch, and other RSS/Atom indexing/search engines) let you search through information as it happens, and follow the interlinking cross-blog conversations. That's incredibly powerful.

I actually just wrote a post on this subject on my blog a few hours ago... *cough*...

I tried some RSS readers an got pretty overwhlemed very uickly by the amount of info.. I switched to RSSFWD and it works much better for me now: http://www.rssfwd.com/rssfwd/ You can easily let the site parse the RSS fro you and then send you an e-mail. No clunky RSS reader required.

I set up a couple of keyword subscriptions to subjects I like in PubSub http://www.pubsub.com/, and then linked to the RSS via RSSFWD. Now I get a few interesting e-mails that are filtered to a folder and I can read when I get a chance.

For sites like Slashdot that I frequent, I just visit the web page. I only use RSS to find info that I might have otherwise missed.

While there are some great ideas in RSS, one of the worst is polling. As discussed in Burton's post, polling results in a ridiculous waste of bandwidth. A Push approach, like the one defined in "Atom over XMPP" would result in a massively more efficient distribution system like the one that we implement in the PubSub Sidebars. But, if you insist on polling, then the best efficiency can be had by combining Gzip with the A-IM or RFC3229+feed as described on my blog. Using RFC3229+feed, your server would only serve up "unread" entries not everything in your feed. Please read and implement: http://bobwyman.pubsub.com/main/2004/09/implementa tions.html

bob wyman
CTO, PubSub.com

While there are some great ideas in RSS, one of the worst is polling. As discussed in Burton's post, polling results in a ridiculous waste of bandwidth. A Push approach, like the one defined in "Atom over XMPP" would result in a massively more efficient distribution system like the one that we implement in the PubSub Sidebars. But, if you insist on polling, then the best efficiency can be had by combining Gzip with the A-IM or RFC3229+feed as described on my blog. Using RFC3229+feed, your server would only serve up "unread" entries not everything in your feed. Please read and implement: http://bobwyman.pubsub.com/main/2004/09/implementa tions.html

bob wyman
CTO, PubSub.com

Technorati only claims to process 900,000 new entries per day - not 9 million. Burton has the number correct in his posting. The /. article quotes him incorrectly. On the other hand, the numbers cited for PubSub are correct. We have processed an average of 1,796,574 (1.8 million) new entries per day over the last 30 days. Many of our statistics are available on our site and updated daily. The "new entries per day" data can be found graphed at: http://www.pubsub.com/linkcounts_graphs.php?type=n ewentries for more graphs and tables, see: http://pubsub.com/linkcounts.php

bob wyman
CTO, PubSub.com

Technorati only claims to process 900,000 new entries per day - not 9 million. Burton has the number correct in his posting. The /. article quotes him incorrectly. On the other hand, the numbers cited for PubSub are correct. We have processed an average of 1,796,574 (1.8 million) new entries per day over the last 30 days. Many of our statistics are available on our site and updated daily. The "new entries per day" data can be found graphed at: http://www.pubsub.com/linkcounts_graphs.php?type=n ewentries for more graphs and tables, see: http://pubsub.com/linkcounts.php

bob wyman
CTO, PubSub.com

Whereas the article title hints to RSS being the new search, it isn't really the case unless you're talking about sites like PubSub which really do convert search queries into RSS (or pushed feeds.)

• Get an alert when google bot runs across a new page that mentions your name.
• Be notified when the when the search engine results page changes for a query that brings your site a lot of traffic.
• Have news results that match your query pop up on your RSS reader.

To get the latest info on the Earthquake, try monitoring this feed from PubSub.com:

http://rss.pubsub.com/ef/c3/b9173332d3d1011651b6f2 bd5f.xml

Content will be updated every 15 minutes and will contain the most recent 32 blog entries that mention the event.

bob wyman

Massive polling for updates leads to scalability problems? Big surprise! We need to learn that HTTP is not always the best technology for the job. Just-in-time content delivery requires a different set of tools. There's already an Internet-Draft for sending Atom feeds over XMPP (a.k.a. Jabber), and the same "publish-subscribe" technology could be used for RSS (or a smart service could translate to Atom so your client doesn't need to parse all those RSS formats). Check out PubSub.com for a real-life implementation of the basic concept (they track 3+ million feeds and notify you when a feed you're interested in has changed, and even do handy keyword-based monitoring). And one added benefit of using the XMPP pubsub extension is that these are all open protocols with many open-source implementations. In this problem-space at least, HTTP is so second-millennium!

Your suggestion is precisely what is defined by RFC3229+feed (i.e. an RSS-specific extension to RFC3229 " delta encoding for HTTP). I maintain a list of implementation of RFC3229+feed on my blog. You can also find some empirical evidence showing massive bandwidth savings as a result of RFC3229+feed use.

This is a well known and "solved" issue...

bob wyman

Your suggestion is precisely what is defined by RFC3229+feed (i.e. an RSS-specific extension to RFC3229 " delta encoding for HTTP). I maintain a list of implementation of RFC3229+feed on my blog. You can also find some empirical evidence showing massive bandwidth savings as a result of RFC3229+feed use.

This is a well known and "solved" issue...

bob wyman

Your suggestion is precisely what is defined by RFC3229+feed (i.e. an RSS-specific extension to RFC3229 " delta encoding for HTTP). I maintain a list of implementation of RFC3229+feed on my blog. You can also find some empirical evidence showing massive bandwidth savings as a result of RFC3229+feed use.

This is a well known and "solved" issue...

bob wyman

"Push" is not enough to solve the problem. What is necessary is a mechanism as brokers to distribute infromation from RSS publishers to RSS readers in Internet scale. It may look like NNTP, but NNTP does not provide content based distribution, only on topic based distribution. Peoples in PubSub Concepts Inc. is working on this problem for a while and they have already create an interesting system using jabber to send out subscriptions from publishers. I think they are welcomed any critisism and participation in create such systems.