Re: Announce: Weblogs.Com changes in RSS

["Bill Kearney" <wkearney99@hotmail.com>]

> > The days of polling RSS feeds for changes need to be a thing
> > of the past. It's just not a scalable way to do things.

How many times do we keep hearing polling is bad and it doesn't 
scale.  Then we hear updates aren't getting routed properly.  Then 
polling comes 'round again.  

Seems like there's a place for both.  Picking the right one differs 
based on your application.  Using one exclusively, I'll argue, is a 
mistake.

> yes! And then you have the problem of finding where to look to

<plug>Why, www.syndic8.com, of course!</plug>

> update notifications.
> If weblogs.com is the only place, it's easy, but will that scale?

Perhaps the clouds can agree to provide an XML document listing any 
other clouds they 'know about'.  Seems fair.  The question then 
becomes do you want to simply let your local toolset ask that 
question from a manually configured first cloud and have 
it 'automagically' build it's list?   Or would you want this to 
remain a manually configured feature in the toolset.

> <channel>
> ...
> <updates>http://www.weblogs.com/changes.xml</updates>
> </channel>
> 
> What do you think?

You mean to let your local consumer of the feed (not just a client) 
know where the feed's source sends it's updates?  That would be 
interesting.  Couple this with the update aggregator supporting an 
announcement of other clouds then it becomes quite viral.

I'd think that you'd want to put some kind of suggested limit on the 
number of <updates> elements in the feed itself.  What if there's 
such an abundance of clouds that the automagic updaters start 
overloading the <channel> element with too many clouds.  (we should 
be so lucky)

This also doesn't address whether they're going to be cgi, XML-RPC, 
SOAP or whatever.  XML-RPC is as good place as any to start it.

This would be an interesting way for feeds to help publicize the 
clouds and vice versa.

-Bill Kearney