Re: Default Pretty Form of DNs

[Pierangelo Masarati <masarati@aero.polimi.it>]

> > typedef struct slap_dn {
> > 	struct berval	dn_raw;
> > 	struct berval	dn_pretty;
> > 	struct berval	dn_normalized;
> > 	LDAPDN		*dn_PRETTY;
> > 	LDAPDN		*dn_NORMALIZED;
> > } SlapDN_t;
> > 
> > with a set of functions that can perform each operation by filling 
> > up the required part of structure starting by the most appropriate
> > member if available, e.g. a dn_normalized can be built from dn_raw
> > by parsing it or by dn_PRETTY by copying it to dn_NORMALIZED and 
> > by normalizing the latter.  Then we can pass this structure instead
> > of two or more bervals as we do now.
> 
> The LDAPDNs are parsed forms (AVAs grouped by RDN) I suppose. I guess
> we can leave all of SlapDN_t (but dn_raw) blank at first. Code that
> need one of the forms, can check if it is filled in, and if not call
> the relevant functions to fill in what they need. This will be like a
> cache then. Maybe it makes sense to have some wrapper code like
> get_dn_normalized(SlapDN_t *) that returns the normalized form (and
> computes and fills in dn_normalized if blank). We don't need to do
> this now of course, we can do some optimizations and code improve-
> ments later. I've been thinking of this caching for about a year now
> I think, this is perhaps what you're thinking as well.

(Stig, reposting to the list in a more complete form because 
I mispelled the address :)

That's exatly what I mean with a "set of functions": smart APIs that 
compute each form of DN starting from the most convenient representation
that's currently present in the SlapDN_t structure, computing each 
intermediate form that might be required.

e.g. starting from the dn_raw form, one might compute the dn_pretty
(which implies producing the dn_PRETTY as well); then, the dn_normalized
from would be computed by COPYING the dn_PRETTY form, applying
the normalization, LDAPDN_rewrite(), and finally computing the 
dn_Rnormalized form.  If only dn_normalized form is required,
the dn_PRETTY form should be computed (maybe an intermediate dn_RAW
could help, i.e. a parsed only structural form), then the
dn_NORMALIZED could be obtained by copying dn_PRETTY and so on.

Everything should pass thru the dn_PRETTY, because dn_NORMALIZED
is not reversible.

BTW: I agree with Kurt, it's too early to start working at this.
I'm only sharing ideas to see if they can grow to any desirable
development :)

Ciao, Ando.