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