Re: about lock tokens

[Angela Schreiber <an...@day.com>]

Dominique Pfister wrote:
> Hi Paco
> 
> On 08/09/2007, Paco Avila <pa...@git.es> wrote:
>> Sorry, I missunderstood the code because confused "lock holder" and
>> "lock ownser" concepts :(
> 
> You're not the only one ;) "Lock owner" should rather have been named
> "lock creator", the current term is absolutely misleading!

btw. for that reason that has been changed in jsr283:

quote from '6.9.4 Lock Owner' of the spec available for
public review:

"If the lock is open-scoped and its ownership is later switched to 
another session, the jcr:lockOwner property is automatically changed 
accordingly. In implementations that support simultaneous lock 
ownership, the behavior of jcr:lockOwner on the addition of an owner is 
implementation specific."

regards
angela

Re: about lock tokens

[Julian Reschke <ju...@gmx.de>]

Angela Schreiber wrote:
> 
> 
> Dominique Pfister wrote:
>> Hi Paco
>>
>> On 08/09/2007, Paco Avila <pa...@git.es> wrote:
>>> Sorry, I missunderstood the code because confused "lock holder" and
>>> "lock ownser" concepts :(
>>
>> You're not the only one ;) "Lock owner" should rather have been named
>> "lock creator", the current term is absolutely misleading!
> 
> btw. for that reason that has been changed in jsr283:
> 
> quote from '6.9.4 Lock Owner' of the spec available for
> public review:
> 
> "If the lock is open-scoped and its ownership is later switched to 
> another session, the jcr:lockOwner property is automatically changed 
> accordingly. In implementations that support simultaneous lock 
> ownership, the behavior of jcr:lockOwner on the addition of an owner is 
> implementation specific."

Thanks for bringing this up.

This change IMHO is an extremely bad idea, because it requires modifying 
the persisted state of the lock, something which may not be possible to 
build on top of existing systems (for instance, those which implement 
the WebDAV locking model which so far has been a super-set of JCR locking).

BR, Julian