W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2004

Re: Bindings and permissions

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 1 Dec 2004 10:21:31 -0800
Message-Id: <D3551436-43C5-11D9-B695-000D93324AD6@gbiv.com>
Cc: WebDAV (WebDAV WG) <w3c-dist-auth@w3.org>
To: Lisa Dusseault <lisa@osafoundation.org>

On Nov 30, 2004, at 1:08 PM, Lisa Dusseault wrote:
> I think I've discussed this before but it's come up again in a use 
> case I'm working on.  In Chandler we want a user to be able to share 
> the same item (for example, a calendar event) in multiple collections. 
>  For example, I might want to show the "OSAF holiday party" in both my 
> work calendar share and my home calendar share, so that other users 
> who view either my work or my home calendar will see the event 
> regardless (and users who share both won't see the event twice).
> The natural way to do this if the server supports bindings would be to 
> create the event in one collection, let's say the client will create 
> it in my work share where permissions are inherited so that all OSAF 
> people can view the event.  Then BIND the event to the other 
> collection, where the inherited permissions normally would 
> automatically make it so that my family and friends can view the 
> event.

That is the most natural way?  I would think that the most natural way 
would be
to have one universal calendar and, when you author an entry in any 
list within it the attributes (calendars/roles/groups/whatever) to 
which it applies.
Your work and home calendars are therefore just virtual collections 
based on the
universal calendar and an attribute mask.  An attempt to author within 
any virtual
calendar will create "bindings" (what everyone else calls resources) 
within all
calendars to which the entry attributes apply.

> I can imagine a server implementing it either way depending on what 
> they think the common use cases are; what can the client predict or 
> require here?

If the client can predict it, then the application has become 
between client and server.

Received on Wednesday, 1 December 2004 18:22:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:33 UTC