Server-to-server channel

Anders Feder lists.anders at feder.dk
Tue Apr 3 22:05:11 UTC 2007


Dick Hardt wrote:
> There are two common client server design patterns. Request / Response 
> and Publish / Subscribe.

I see - I was not aware that the latter model was so well-understood in 
the client/server paradigm.

> The RP has what ever the user last gave the RP. If the user is 
> involved in the transaction, the RP may ask the user for up to date 
> information.
> Note that your concern is constrained to situations where the user is 
> not involved.

It is, but will automated transactions not make up a significant portion 
of the communications on the service-oriented Web?

>> * If an OP fails to update an attribute, the RP will never know - no
>> fall-backs can be implemented.
>
> When the data changes, the user then decides if the RP gets the data. 
> If the user did not want the RP to get, well that is what the user 
> decided. This is user centric after all.

I see the merits of user-centricism, but what happens if a user do want 
an RP to receive an update but the RP is unavailable?

For instance, imagine I have ordered a secret product from an RP. Before 
my order is fully processed, circumstances force me to move to another 
(postal mail) address. If the connection to the RP is not available when 
updating my mail address attribute on the OP, for whatever reason, the 
RP will send the secret package to my old address and whoever lives 
there now.

>> * When updating, the OP impose a previous address structure upon the
>> Web, regardless of how it is actually organized now.
>
> The converse would be the RP imposes an address structure on the OP on 
> where to get the updated data.

And rightfully so, because the user selects his OP based on his trust 
that its address structure will not change - this is the key principle 
in OpenID.

> Well, the OP would be responsible for responding to all the myriad 
> useless RP requests for updated data if a pull model.

Good point :) In most cases you are probably right, but one can imagine 
attributes, especially in futuristic scenarios, which are almost 
inherently 'pull' (like GPS data) such that translating them into 
'pushes' are immensely ineffective. But I guess 'push' is per-attribute 
optional, in that case?

>> information to RP's it has no direct interest in. A malicious RP may
>> even exploit this storage space for own purposes.
> * The OP must donate storage space to support the distribution of
>
> The alternative would be the OP would need to donate storage to 
> support which RPs are allowed to ask for data.

Only if the user actually wish to restrict access - and the RP would not 
have access to this storage.

Anyway, I'm convinced you have thought it through. "Pull" relates to 
"push" as quantum mechanics relates to relativistic physics - but very 
often quantum mechanics is overkill.

Regards,
Anders Feder



More information about the specs mailing list