> Here is some of my comments: > > A. I am a supporter of the A-2. > > B. I believe in deleting history content that are not referenced by VCRs. > Does DeltaV specify what should happen with the VHRs when VCR's are deleted?
VHRs should not be deleted when the corresponding VCRs are deleted. Just like with CVS you shall be able to retrieve versions after you have deleted the VCR. Note that you can delete the VHR explicitly. Just a remark, Ingo > > C. I like the idea that all history VRs inherits ACL from the VHR. > > D. From what I understand the DAV:inherited-acl-set makes an AND operation > on ACLs inherited from other resources. If all VHR has an ACL that grants a > "root" account all privileges and then makes an OR operation with the ACLs > of the VCRs that referes to this VHR. > > One more thing about the history folder. Would it be possible to make a non > inheritable ACE on the history folder that prohibits read? Why would anyone > need to list the content of the history folder - only access to the VRs in > the VHRs makes sense - or am I wrong. > > I have a tendency of getting lost when I read these specifications, so I > hope this makes sense :-) > > /jacob > > ----- Original Message ----- > From: <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 13, 2004 11:54 AM > Subject: RE: Structure of history folder > > > Any news or comments about this issue? > > Regards, > Peter > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 06, 2004 10:55 > > To: [EMAIL PROTECTED] > > Subject: RE: Structure of history folder > > > > > > 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] > > > > > > --------------------------------------------------------------------- > 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]
