-
Notifications
You must be signed in to change notification settings - Fork 15
Open
Labels
I2Regular impactRegular impactS2Regular significanceRegular significanceU2Seriously plannedSeriously plannedfeatureCompletely new functionalityCompletely new functionality
Milestone
Description
Is your feature request related to a problem? Please describe.
I'm always frustrated when I can't restrict how LOCK operation is available or not to users. Currently it's a PUT of LOCK object wrt ACL restrictions.
Describe the solution you'd like
Add a LOCK verb. It's pretty straightforward for EACL and tokens, however there is a problem of basic ACL. It can be solved in different ways:
- treat it the same as PUT there
- repurpose one of the (mostly) useless verbs like GETRANGEHASH (can be combined with reserved bit flip, we've got two spare there)
- extend basic ACL with one more integer
- extend basic ACL type to uint64 (in a different protobuf field of course)
- use an attribute for additional basic ACL integer
- move basic ACL to attributes altogether
Each has its pros and cons.
Describe alternatives you've considered
We need LOCK itself, the operation is radically different from PUT and it can be useful to not mix them (allow to PUT and forbid LOCK or allow LOCK and forbid PUT).
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
I2Regular impactRegular impactS2Regular significanceRegular significanceU2Seriously plannedSeriously plannedfeatureCompletely new functionalityCompletely new functionality