[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Push vs. Pull?


Hi Bod,

On Jan 11, 2004, at 20:38, Bob Wyman wrote:

petite-abeille (little bee) wrote:

Thanks for the translation. I'm sure our non Francophone readers will appreciate :)

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.

Amen :)

That's
exactly why such mechanisms already exist.

Yes. There is nothing new in any of this. However, and as far as syndication goes, they are not that common. Or did I miss something?

 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

Of pulling? Or pushing?

 and why
something "Atom specific" is necessary or useful?

This is an open question. I would much more prefer to reuse something that already exits instead of reinventing the wheel. That said, reuse get you only that far. And no, reusing Rendezvous (of the Tibco kind) in not an option for me :)

    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.

Perhaps. This mostly depend on your blog topology. If one is dealing with the current Command & Control structure, then yes it may be a problem if handled naively. On the other hand, if your topology is more distributed, this may turn out to be a non-issue.

    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...)

Right. But once again, we are getting lost in implementation details which presume that such notification mechanism is there to run some critical infrastructure of the Federal Reserve Bank. It is not. And if it turns out to be, such issues would be better handled by the underlying transport/distribution mechanism than by any specific notification protocol itself.

     There are obvious solutions to the problem that involve
mixing polling, push, centralized sites, etc. however, those
are for a later message...

Looking forward to it :)

Cheers,

PA.