Interface Change: Lock and Security Child Store

["Pill, Juergen" <Ju...@softwareag.com>]

The child store interfaces for security and locking do now support an
additional parameter, which contains the revisionDescriptor. This allows to
put a lock (or security) on a specific version only.
Currently this parameter is NULL is most times.

If you develop a child store, you will need to adopt your interface. Please
do currently not use this additional parameter, because in most cases it
will be NULL. Additional efford should not be introduced. Hope you do not
have too much inconvience with this change.

All the child stores distributes with Slide have been changed accordingly!

Best regards

Juergen Pill




-----Original Message-----
From: Pill, Juergen [mailto:Juergen.Pill@softwareag.com]
Sent: Friday, May 04, 2001 9:27 AM
To: 'slide-dev@jakarta.apache.org'
Subject: RE: Next release (propose child interface change)


Hello,

I want to suggest an API change in the child stores before we go into final
release (we talked about this some time ago).

Currently the security and lock child stores receive the uri (and the
permission/lock) as parameter only, but not the revisionNumber. This leads
to the fact, that Slide can lock only all versions or all versions are
unlocked (same applies for security, different versions of a resource may
not have a different set of permissions). If we would extend those
interfaces with the revisionNumber/revisionDescriptor, different versions of
a resource may be locked by diffferent idividuals and some versions may not
be locked at all.

What do you think? Do you want me to change these interfaces and modify the
Slide layer accordingly next week?

Best regards

Juergen Pill


 

-----Original Message-----
From: Remy Maucherat [mailto:remm@apache.org]
Sent: Friday, May 04, 2001 1:53 AM
To: slide-dev@jakarta.apache.org
Subject: Re: Next release


> I'll try and get the important change to you by Saturday.
>
> Not to start a long discussion, but what's the policy with respect to
> changing interfaces after they're published?  I tend to lean towards the
> "interfaces are immutable, after they're published they may not be
changed"
> policy.
>
> But I realize the definition of "published" is different for Open Source
> software.

Yes, I also think that incompatible API changes must be avoided at all
costs.
Of course, if it turns out there's something really broken, it has to be
changed (that happened some time ago with the transaction related API, and
more recently with the split of the WebDAV client library).

> Anyway, I mainly wanted to clean up the interface before it got exposed to
> the public.

No problem.

Remy

Re: Interface Change: Lock and Security Child Store

[Remy Maucherat <re...@betaversion.org>]

Quoting "Pill, Juergen" <Ju...@softwareag.com>:

> The child store interfaces for security and locking do now support an
> additional parameter, which contains the revisionDescriptor. This allows
> to
> put a lock (or security) on a specific version only.
> Currently this parameter is NULL is most times.
> 
> If you develop a child store, you will need to adopt your interface.
> Please
> do currently not use this additional parameter, because in most cases
> it
> will be NULL. Additional efford should not be introduced. Hope you do
> not
> have too much inconvience with this change.
> 
> All the child stores distributes with Slide have been changed
> accordingly!

Good idea overall, but I think this is a complex problem. For example, there 
are some cases which are unspecified right now, like inheritance).

I'd like to make this counter-proposal (although it's not really a counter-
proposal, since it mostly clarifies things a bit) :

- Use NodeRevisionNumber instead of NodeRevisionDescriptor. The rationale is 
that you don't need an access to a store to get a NRN.
- Allow global locks, and global ACLs. By global, I mean which would apply to 
all revisions of the object. We should take advatage of the possibility for the 
NRN parameter to be null.
- Leave in the old methods (which would of course call the new methods with 
null as the NRN parameters).
- Clearly state that only global locks and ACLs can be inheritable. I don't 
think it makes sense to say that principal foo will have write permissions on 
revision 1.3 of /bar and all its children.
- Actually, instead of modifying the calls in the lock helper and the security 
helper, I would add the NRN as a (possibly null) field of NodePermission and 
NodeLock. That way, we don't change any of the current interfaces.

I was planning to rewrite the security checking algorithm, so I think I'll add 
the revision checks at the same time.

Remy

> -----Original Message-----
> From: Pill, Juergen [mailto:Juergen.Pill@softwareag.com]
> Sent: Friday, May 04, 2001 9:27 AM
> To: 'slide-dev@jakarta.apache.org'
> Subject: RE: Next release (propose child interface change)
> 
> 
> Hello,
> 
> I want to suggest an API change in the child stores before we go into
> final
> release (we talked about this some time ago).
> 
> Currently the security and lock child stores receive the uri (and the
> permission/lock) as parameter only, but not the revisionNumber. This
> leads
> to the fact, that Slide can lock only all versions or all versions are
> unlocked (same applies for security, different versions of a resource
> may
> not have a different set of permissions). If we would extend those
> interfaces with the revisionNumber/revisionDescriptor, different
> versions of
> a resource may be locked by diffferent idividuals and some versions may
> not
> be locked at all.
> 
> What do you think? Do you want me to change these interfaces and modify
> the
> Slide layer accordingly next week?
> 
> Best regards
> 
> Juergen Pill
> 
> 
>  
> 
> -----Original Message-----
> From: Remy Maucherat [mailto:remm@apache.org]
> Sent: Friday, May 04, 2001 1:53 AM
> To: slide-dev@jakarta.apache.org
> Subject: Re: Next release
> 
> 
> > I'll try and get the important change to you by Saturday.
> >
> > Not to start a long discussion, but what's the policy with respect to
> > changing interfaces after they're published?  I tend to lean towards
> the
> > "interfaces are immutable, after they're published they may not be
> changed"
> > policy.
> >
> > But I realize the definition of "published" is different for Open
> Source
> > software.
> 
> Yes, I also think that incompatible API changes must be avoided at all
> costs.
> Of course, if it turns out there's something really broken, it has to
> be
> changed (that happened some time ago with the transaction related API,
> and
> more recently with the split of the WebDAV client library).
> 
> > Anyway, I mainly wanted to clean up the interface before it got
> exposed to
> > the public.
> 
> No problem.
> 
> Remy
>