Lists Home |
Date 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:firstname.lastname@example.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
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