Re: Push vs. Pull?

[Bob Wyman <bob@xxxxxxxx>]

petite-abeille (little bee) wrote:
> perhaps it would make some sense to have a more 
> "proactive" way of knowing about updates.
    Sure, it would be good to have such a mechanism. That's 
exactly why such mechanisms already exist. As you point out, 
Winer has defined his "cloud" and there are other push 
interfaces in use. But, before you go too far in defining 
something Atom specific, how about first making a case for 
what is wrong with the existing mechanisms and why 
something "Atom specific" is necessary or useful? 
    Consider as well that wide deployment of push 
notifications might have some unfortunate side effects:
    1. If every blog provides a distinct push service, then 
for many blogs, you're going to see potentially large numbers 
of notifications being sent out whenever an entry is updated 
or created. i.e. if I have 1,000 people "subscribed" to my 
blog then I would need to send out 1,000 notices each time I 
do an update. This could get ugly and could waste a great 
deal of bandwidth, machine resource, etc.
    2. If each of the 1,000 subscribers immediately fetches 
my blog as soon as they get a ping from me, then what I'll be 
doing is giving myself the Slashdot effect everytime I do an 
update! Thus, I'll probably end up having to write code to 
bleed out the updates over a period of time in order 
to "shape" the response curves so that my peak load is 
manageable. (Algorithms for building notification release 
strategies that produce optimal response curves are actually 
quite a fascinating subject -- but a bit complex...)
     There are obvious solutions to the problem that involve 
mixing polling, push, centralized sites, etc. however, those 
are for a later message...

    bob wyman