[Date Prev][Date Next]
Re: denyop (Was: commit: ldap/servers/slapd/back-monitor back-monitor.h database.c init.c proto-back-monitor.h)
> I would separate the two issues based on the context they may be used.
> This would clarify that both attributes (at least both principles) are
> useful. The "denyop" approach should be intended as a means to
> fine tuning what operations a database can be used for; the "readOnly"
> apporach would be rather administrative, i.e. used by an administrative
> entity to operate temporary mode changes, e.g. right before changing the
> configuration in a way that requires disabling of write operations (e.g.
> the schema is being changed, a replica is being added or so).
> In this sense, "denyop" would be nearly permamnent, and fine tuning is
> desirable; "readOnly" would be mostly temporary, and coarse but
> quick'n'easy write disabling would be preferable. In this sense I'm in
> favour of a multi-valued "denyOp" attribute, plus a boolean "readOnly"
> that, when set, overrides the write "denyOp" values (simply, it's
> honored before "denyOp" is checked).
I just committed some code to enable selective modification of readOnly
and restrictedOperation attributes in what I think is a consistent manner
(if any can be defined). The approach is opposed to what Howard used for
the readOnly attribute only, and I'm sure there are issues left;
essentially, readOnly and restrictedOperation act on the same underlying
data, and the former essentially acts on a subset of the latter. One
issue is, for instance, that if we consider readOnly a shortcut to disable
write operations, if applied to a database that already restricts some
operations there is no easy way to revert it, e.g.
# apply readOnly=TRUE
# apply readOnly=FALSE
The final status differs from the initial one.
Feel free to suggest changes, or to revert the changes.
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497