[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: back-config again

> I'd really like to see cn=config and cn=monitor (which also
> supports some server administrative capabilities) merged.
> That is, a single database object can and should be used to
> "manage" the database (configure, monitor, or otherwise
> administrate).

This could be a possibility; I note (I think Howard already listed this)
that in relation to back-config changes can be:

1) persistent/temporary
2) take place immediately/deferred

back-monitor currently implements changes that take place immediately
and are temporary; back-config will need to be able to do the same,
but will also need all the other three combinations.
Moreover, back-monitor is mainly intended to present the status
of subsystems without allowing any modification; this is true
for most of the entries.  But many of them will be affected
by back-config, since they depend on the configuration of the server.

For instance:

backend info could be loaded run-time, by implementing a backend
subsystem that allows the writing of a new entry consisting
in the location and the parameters of a dynamic module.

database info could be changed runtime, by implementing a database
subsystem that allows the writing of a new entry that activates
a new database.  Note: in this case we could also consider
the possibility to store that data in a subtree of the suffix itself,
e.g. for a suffix "dc=example,dc=com" in "cn=Config,dc=example,dc=com"

Of course, if "cn=Config" will contain info about databases
and backends, with the possibility to change them via protocol,
I no longer see the need to duplicate this info in back-monitor.
At this point, we could clearly separate the interface between
the two, by leaving to back-monitor the monitoring of dynamic data
(e.g. connections, stats and so), or completely merge the two.

I see a logical distinction between config and monitoring, but
it's not mandatory that we preserve it at the interface level.

I'm totally in favour of the object-oriented approach for the
configuration; I'd prefer dedicated entries for the subsystems
rather than adding too many aux classes to "cn=Config".


Pierangelo Masarati