Hi Ingo. I see your point, but how do you clean up the history for old non referenced VHRs?
>From what I can see, there is no way of telling from what VCR the VHR was generated - or am I wrong? I am simply trying to figure out how to maintain a slide server for a longer period of time without having too much garbage in the history. /jacob ----- Original Message ----- From: "Ingo Brunberg" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 13, 2004 1:16 PM Subject: Re: Structure of history folder > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
