> Howard,
>
> > That's exactly what I had in mind. That's why the issue of correctly
> > massaging DNs is so important.
>
> Right.. what I had in mind specifically was "imposing" one namespace
> on top of another, for example, joining the dc=padl,dc=com namespace
> from separate directories into one. Perhaps (for creating entries)
> you could assign automony for parts of the schema to certain
> directories, so were I to create an entry that is both User and
> posixAccount, the User attributes end up on Server A and the latter
> on Server B.
>
> Some massaging may be in order, yes, particularly if you join on
> an attribute which is not in the RDN.
OK, now I follow you. Compound objects, essentially. Yes, nice to have. It's
on my to-do list as well, but further down... So far the only thing I can
think of is to have subentry attributes specifying a "see also" DN. Querying
for just the object will get you the compound object, but you can still
explicitly query the subentry info to see what the object is composed of. To
support creation/
modification, I guess the subentry needs to enumerate exactly which
attributes
are derived from which other locations. It's not entirely clear to me how to
configure something like this.