Tom wrote:
> Don't worry, I'll veto any immediate removal of functionality ;-)
> The correct way to handle this is to add some better userlock
> functionality and deprecate what's there. We can remove the crufty
> stuff in a release or three after it's been officially deprecated
> ... but there is no reason to remove it immediately. It won't
conflict
> with a better version, just exist alongside.
hm. how about this: leave the userlock contrib module completely alone
and call them 'application locks' (what is the 'user' in userlock?).
Basic points:
1. tweak sources replacing 'user' with 'application' in various places
2. application locks interface is in core project and properly
documented
3. provide 64 bit (or more?) lock space...oid plays no direct role
4. deprecate userlock module but leave it otherwise unchanged.
5. add string based locking to the interface?
Merlin
