Re: [ldapext] Dynamic values in LDIF

Michael,

As I said, my original post must be lacking...

What I'm asking for is something like this:

1) An LDIF assignment record. This could look like other LDIF records except there would be no changetype. It might looks something like this:

# the application updating schema assumes dc=example,dc=com exists. It is going to update schema for this entry

# if the application plans to update schema for objects subordinate to this, it assumes that the schema AP for this entry also

# applies to the subtree below it. If it cannot make this assumption, it can perform this assignment/schema update combination

# for each entry it plans to update.

dn: dc=example,dc=com

recordtype: assign

myBase: subschemaSubentry

2) An LDIF substitution mechanism. This could be anything, but I'm using the url construct as a simple example. It might look like:

dn: <localfile:///myBase>

changetype: add
# remainder of record to update the schema governing dc=example,dc=com

If the subschemaSubentry attribute on dc=example,dc=com is cn=schema,dc=com, it will be substituted as the dn value for the change record.

Note that the machine (host:port), authN credentials, and connection-oriented stuff is handled by the tool (like ldapmodify) being used to apply the ldif. The assignment record assumes the DSA to which the ldif is being applied.

But I doubt anyone with the time to extend LDIF is going to pick this up, so it doesn't matter anyway.

Jim

>>> Michael Ströder <michael@stroeder.com> 11/8/04 2:54:03 PM >>>
Jim Sermersheim wrote:
>
> >>>> Michael Ströder < michael@stroeder.com > 11/8/04 3:15:25 AM >>>
> >Jim Sermersheim wrote:
> >>
> >> It's difficult (well, impossible I guess) to write an LDIF file which
> >> can be used to update schema because one never knows the name of the
> >> subschema subentry in effect for the object(s) for which the schema
> >> is being updated. (I'm assuming a DSA which can modify schema. i.e.
> >> X.501(93) Clause 14.5).
> >
> >There's not a single sub schema sub entry. In fact there could be many.
> >=> you have to know something a priory about the DSA before updating one
> >of its sub schema sub entries.
> Exactly (thus the "in effect for the object(s)" bit). This is why I'm
> wondering about a mechanism to (apriori) gather the knowledge needed to
> update the schema which the application intends to update.

Kind of a mind-reading machine? ;-)

Well, if someone would like to implement a generic sub schema modifying
program this would need as input params to modify a certain sub schema
at least:
- machine (host:port)
- naming context
- authentication credentials
- some connection-oriented stuff (e.g. LDAPS to a separate port)

Frankly I have no clue how these params could be guessed. They are given
at run-time by an admin who simply knows them. Now if you invoke a
program with params you can't guess you can easily implement all your
sub schema modifications in that program.

> I apparently worded my message poorly. My intent is to NOT have to
> implement anything other than an LDIF file.

I can imagine quite well what you want. IMO it's simply not possible
without some program interpreting the LDIF data within some context
known a priori.

Ciao, Michael.