OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] RSS beyond the Blog: 1992 or 1999? - was Re: [xml- dev] h

[ Lists Home | Date Index | Thread Index ]

At the record level, I believe you are right.  On the other 
hand, one might be subscribing to a list of known offenders 
for which the aggregator would be effective.   So worse 
is worse seems to also have a scale or granularity 
component.  One of the features we would need is a means 
to determine if a subscriber has subscription privileges 
depending on the content.

I'm glad to see you thinking that through.  I'm not sure 
what the opposite of FUD is but it must have something to 
do with 'unreasonable optimism for marketing and colonization'. 
Anyway, Tim was being reasonable in that what he said was 
the technologies excited people.  If he is the advance man, 
he'll be thinking this through too.

But this is interesting because one can envision different 
levels and conditions for syndication technologies where the 80/20 
trade-offs won't apply equally.


From: Michael Champion [mailto:mc@xegesis.org]

I think so.  An RSS aggregator just polls the sites it syndicates 
periodically to see if there is anything new.  There are many things 
that they can do to make this relatively efficient for both the 
syndicating site and the end user, but *architecturally* this seems 
doomed to non-scalability as the number of feeders and readers grows.  
It will continue to work fine for popular news sites and weblogs, it 
won't work so well for subscribing to highly specialized information.  
A real publish-subscribe mechanism in which those making the changes 
notify those who have registered an interest in changes (perhaps via an 
intermediary to take the burden off the site hosting the system that 
made the change) is the kind of thing you're talking about, as I 
understand it.

The reason I used your name  is that the current RSS polling 
infrastructure seems like one of those "good enough for the simple 
stuff" systems that tend to get baked into concrete even though 
"better" alternatives are clearly possible, and may be necessary to 
make this support critical applications like banking.  The open 
question to me is whether this is one of those "80/20 rules" scenarios 
Tim Bray discusses, or one of those "worse is better is really worse" 
scenarios that you frequently mention.  In this particular case, I'm 
leaning toward "worse is worse." 

The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS