> I'm not sure I understand the question. For the specific case of
> items moving from core.schema into the code, we would ship a new
> schema file and discard the old one, just as we do now. Since the
> server needs to be restarted for the new schema_prep code to take
> effect anyway, the old schema file can simply be replaced.
It is my understanding that as soon as you store back-config data
into the underlying database, the slapd.conf is no longer used. So
the only way to have the new schema files parsed in is remove the
underlying (back-ldif) database and start from scratch, but I'm
afraid this would not preserve changes occured via protocol. Or am I
missing something?
> I suppose we should be prepared to start distributing LDIF schema
> files. But regardless, I see this as an offline / manual update
> process; you can just edit the back-ldif files directly or replace
> them with new copies.
This is an option; I considered that, although it might be error
prone as the underlying database should be mainly accessed via API
and not manually (and it could eventually become a back-bdb, and I
envisage sci-fi scenarios where back-config is using back-ldap for
remote storage of the configuration...;)