Re: Bindings and permissions

On Dec 1, 2004, at 10:21 AM, Roy T. Fielding wrote:

> 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 
> calendar,
> 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've seen the "universal calendar" approach as well (called "one big 
soup"), so obviously there is more than one natural way but of course 
it depends on your network architecture and use cases. The big soup 
approach certainly works for one server site.  But when you try to view 
one calendar on one site and another calendar on another site (run by 
different IT departments) things stop working the same way.  So if you 
begin with the understanding that the user is going to access a set of 
calendars distributed across a set of repositories administered by 
different people, the big soup (on one site) starts to be a special 
case that is unnecessarily different from the general case.

Another reason I didn't mention the big soup approach is because that 
requires server support.  I'm working on a rich client and we'd rather 
minimize the number of new, specific features that must be added to the 
server in order to get this kind of scenario working.

Finally, whenever you require special server support -- creating 
virtual collections based on event attributes -- that limits the 
flexibility of clients to decide for themselves how the collections 
should be structured.  You could try to define a generic server feature 
to support this (e.g. dynamic-membership collections based on the 
results of a rule set) and return control to the client, but that 
generic server feature is nowhere near the level of support and 
standardization that bindings has.


>> 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 
> tightly-coupled
> between client and server.
>
No, it just means that the range of options open to the server has been 
closed down to a smaller set of options.  Defining a standard always 
involves that.

I'm not suggesting full client predictability, that's impossible in 
practice.  I still think it advisable to close down the options 
available to servers, in order to reduce unpredictability somewhat.

Lisa

Received on Thursday, 2 December 2004 01:22:02 UTC