[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: partial locking and access control
Martin Bjorklund wrote:
Phil Shafer <email@example.com> wrote:
IMHO the data model needs to define what's lockable. Supporting
random XPath expression locking is way too expensive.
Note that random XPath is only supported if the :xpath capability is
supported. Implementation-wise, if your code handles :xpath, it will
not be more expensive to handle random xpath for partial locking.
(That's what we do in our implementation - we just send the xpath to
our xpath evaluator, and it will return a node set. Each node in the
node set will be locked. For a xpath filter in a <get>, we just use
the same xpath evaluator but sends the selected nodes in the
IMO, random Xpath should be a vendor extension.
Prove that it works for locking (I don't think it does.)
Take the ifAdminStatus example.
This is a valid use-case.
The operator needs to specify the desired lock in a way
that does not change between compile-time, rule-config-time,
The ncx-acm access control model uses a list of QName strings
as one way to specify an rule target. The QName 'itf:ifAdminStatus'
is sufficient to satisfy this basic partial-lock requirement.
(Maybe if I knew Xpath better I would think it was a hammer
encrusted with such fantastic precious metals that I would
clearly want to smash on more nails with it. ;-)
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.