RE: commit: ldap/servers/slapd/back-monitor back-monitor.h database.c init.c proto-back-monitor.h

["Pierangelo Masarati" <ando@sys-net.it>]

>> -----Original Message-----
>> From: owner-openldap-devel@OpenLDAP.org
>> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Pierangelo
>> Masarati
>
>> > A much simpler reason - if you set the Global readOnly
>> flag, there is no
>> > possible way to reset it, because all subsequent LDAPModify requests
>> will be rejected.
>>
>> We could solve the chicken-and-egg problem by allowing this type of
>> modify to rootdn only; of course it has to be rootdn of the
>> server, not of a specific backend.  I'm more and more in favor
>> of having a global BackendDB structure that holds global data,
>> making all global operations mimic those of a regular backend.
>
> That would certainly help solve some of these issues. It might make
> sense to pursue this further, and implement the rootDSE, cn=SubSchema,
> and a few other nodes as objects under the global backend.

It could much resemble the approach of back-monitor (and back-monitor
could be swallowed by it), i.e. a reduced API set (with respect to
that of regular backends) that provides hooks to create/update/modify
entries and hooks for descendants, whose hooks can be different.
Create should occur at startup and, for dynamic entries, when requested;
update should occur whenever they depend on dynamic data and access is
requested; modify for special entries tha support user/admin
modifications, e.g. schema manipulation, rootDSE supported features
manipulation and so.

If the global backend does not recognize the naming context of the
incoming request, a regular backend would be selected.  In other words, it
would just be a wrapping around what's currently done, which should ease
extensions and generalization of what's currently done on a per name
basis.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it