Push vs Pull

[Dag Arneson]

Martin Atkins wrote:
> Imagine a long, thin room with a person standing at each small end. The
> first person is Mr Client and the second person is Mr Server.
> 
> Mr Server has a box containing a piece of paper that says "Martin's
> surname is Atkins".
> 
> In the "Pull" situation, Mr Client decides that he wants to know
> Martin's surname, so he gets out a rope and makes a lasso. He chucks the
> lasso around Mr Server's box and then pulls it to him.
> 
> In the "Push" situation, Mr Server decides that Mr Client needs to know
> Martin's surname, perhaps because Mr Client is friends with Martin and
> Martin's surname has changed recently. Mr Server kicks the box briskly
> across the room to Mr Client; Mr Client doesn't know what's in the box
> until he recieves it and takes a look inside.
> 
> Mr Server knows who Mr Client is in both situations. Responding
> differently to differently clients is orthogonal to the notion of "push"
> and "pull". The difference is that for "pull" the reciever of the
> information actively asks for it, while for "push" the sender just
> transmits it to the reciever at an appropriate time without direct
> provocation.
> 

That makes more sense.  I was confused before with all the oblique 
references to "Push", and what I had gleaned (incorrectly) didn't 
correspond to my traditional understanding of the word "push".  And I 
know that the quickest way to get the right answer to a question on the 
internet is to post a wrong answer and wait for people to correct it. ;)

Regardless, here's a new attempt at a brief definition:
Pull:  Data is transmitted in response to a query
Push:  Data is transmitted unsolicited

There's a slight difference between what you said (and I tried to 
restate in my definition) and what Dick said, replying to Joaquin in 
this thread.  As Dick defines Push, it requires a POST or the equivalent 
from the user:
 > - The user "Pushes" the data to the Relying Party
 > - The repository does not need to be accessible to the Relying Party. 
 > This allows the data to reside on the user's machine.

Whereas you appear to be defining it more broadly, so that the user's 
Identity Provider could be doing the pushing on the user's behalf.  This 
approach seems to me to have an advantage in the following situation: 
Suppose I change my email address, and I want to tell all the sites on 
which I have accounts about the change.  While it would be possible to 
feed the user agent some javascript which caused successive pushing of 
the data to each site, it would be cleaner to have the Identity Provider 
do the pushing on the user's behalf.  In this fashion the user can 
update their profile data on just one site, and have it updated on all 
the sites they visit. (provided they support whatever protocol)

That is assuming that there's no change to the user agent; a browser 
plugin or some other software running on the user's computer opens up 
the possibility of storing the data locally to the user and submitting 
it to sites directly.  Such software would allow a user to become their 
own identity provider, and provided the protocol is correctly designed, 
it could even use the same protocol as the remote Identity Provider in 
the previous paragraph.


> I'm having trouble thinking of use cases for "push" where Yadis is
> concerned. Yadis could be used for capability discovery of a Push
> endpoint, but that doesn't change Yadis at all; the capability discovery
> step is still a Pull, even if what follows is a push.
> 

As I see it, Yadis can be used for Push in two ways:  A Relying Party 
can use Yadis to advertise a URL that accepts a Push, and a user can use 
it on their ID URL to advertise that they support (or their Identity 
Provider supports) a given Push protocol.