Permissions on histories [was: Structure of history folder]

[Pe...@softwareag.com]

Hm ... I think there are two open issues around version histories:

1) the structure of the history folder (currently the folders /history
and /history/nnn can get big in terms of #members)

2) how do the permissions on version histories relate to the permissions
on the original resources? [this thread - although the subject suggested
it was issue #1]

Regards,
Peter

> -----Original Message-----
> From: Oliver Zeigermann [mailto:ozeigermann@c1-fse.de]
> Sent: Thursday, May 13, 2004 11:59
> To: Slide Developers Mailing List
> Subject: Re: Structure of history folder
> 
> 
> I have no real idea of DeltaV, but I think applying the 
> history folder 
> workaround by Martin Holz is not the best solution. We should rather 
> find out why it is slow to access collections with many children.
> 
> Oliver
> 
> Peter.Nevermann@softwareag.com wrote:
> 
> > Any news or comments about this issue?
> > 
> > Regards,
> > Peter
> > 
> > 
> >>-----Original Message-----
> >>From: Peter.Nevermann@softwareag.com
> >>[mailto:Peter.Nevermann@softwareag.com]
> >>Sent: Thursday, May 06, 2004 10:55
> >>To: slide-dev@jakarta.apache.org
> >>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:ozeigermann@c1-fse.de]
> >>>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: slide-dev-unsubscribe@jakarta.apache.org
> >>>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>------------------------------------------------------------
> ---------
> >>
> >>>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>>
> >>>
> >>
> >>------------------------------------------------------------
> ---------
> >>To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> >>For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> >>
> >>
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: slide-dev-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org