Yes, it sounds pragmatic and good to me too. Unfortunately, both specs (DeltaV and ACL) are silent WRT this problem. Some time ago we, at Software AG, tried hard to find an appropriate solution ... but didn't succeed :(
Here are some questions/remarks: A) AFAIU the idea is to let *all* VRs of an history somehow *dynamically* "inherit" the ACLs from another resource. Right? Could it be: 1) from one specific VR of the history? a) which one? root VR? latest VR? (there can be many latest) b) how does it get its ACL initially? 2) from a VCR? a) what if multiple VCRs are related to the same history? b) take the VCR from an assumed "global workspace"? B) If A-2 is correct: what if the VCR is deleted and the history remains ... what are then the persmissions of the history? C) If all VRs of a history should have the same set of permissions, these are ideally defined at the VHR and inherited over the namespace hierarchy? D) The ACL spec defines a strange "inheritance" mechanism over the DAV:inherited-acl-set property: "This protected property contains a set of URLs that identify other resources that also control the access to this resource. To have a privilege on a resource, not only must the ACL on that resource (specified in the DAV:acl property of that resource) grant the privilege, but so must the ACL of each resource identified in the DAV:inherited-acl-set property of that resource. Effectively, the privileges granted by the current ACL are ANDed with the privileges granted by each inherited ACL." Could this property help? Did you (Mike O.) use it in your solution? Regards, Peter > -----Original Message----- > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 05, 2004 09:02 > To: Slide Developers Mailing List > Cc: Nevermann, Dr., Peter > Subject: Re: Structure of history folder > > > To me this sounds good. What does Peter say to all this as I > understand > he has written most of the DeltaV code. > > Peter? > > Oliver > > Michael Smith wrote: > > Michael Oliver wrote: > > > >> I believe that the current permissions on the current > version should be > >> applied to all versions and not the permissions at the > time the version > >> was created. This is how we did it with Livelink and our > reasoning at > >> the time was as follows: > >> > >> 1) If a user is removed from access to the current version, this is > >> usually because the owner of the document wants the content of the > >> document removed from view for that user (or group). > >> > >> 2) If a user is granted access to a document, then all > previous versions > >> are also granted, for a similar reason. > >> > >> 3) Access to specific versions without access to all versions was > >> possible in Livelink with a concept we called > "generations" that allowed > >> a specific version of a document to appear to the system > as a separate > >> "generation" document. > >> > > > > Michael, > > > > This sounds fairly reasonable. My suggestions before were > not intended > > as a "this is the way it should work", but more intended as > a way to > > spark some discussion of the possible approaches - looks > like it worked :-) > > > > The "generations" stuff looks interesting - but somewhat > unrelated. I > > think we can (should) probably implement just 1 & 2 initially. > > > > Mike > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
