Lists Home |
Date Index |
On Mar 18, 2004, at 4:20 PM, Bullard, Claude L (Len) wrote:
> For example, in my business, an agency/officer can subscribe to
> a record change or the entry of a record with some
> information of some kind (say, anytime some one makes
> a query with the name 'Len Bullard' in it). That is
> likely beyond the sort of tech we are discussing here, yes?
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."