[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: SLAPI and add requests

> I notice that the preoperation plugin only has access to a
> skeletal entry, ie. without any attributes filled in. The
> complete entry should be available as SLAPI_ADD_ENTRY.
> For example, it is often useful to have a preoperation add
> plugin set a default for an attribute:
> 	...
> 	if (slapi_entry_attr_find(entry, "someAttribute", ...)) {
> 		/* entry already has attribute; do nothing */
> 	} else {
> 		/* set the attribute to some reasonable default */
> 		slapi_entry_attr_set_charptr(e, "someAttribute", "someDefault");
> 	}
> 	...
> I would like to fix this, but it's going to involve shuffling
> some code around in servers/slapd/add.c (the modification list
> will need to be turned into an entry much earlier on).

Also, note that recently I optimized the modlist handling
which was turned to doing almost linear normalization where
its cost used to be quadratic; this made the code little readable,
so you should be very careful not to break its sematics nor the
optimization (which was dictated by terrible performances
when administrating groups with large number of members,
a hot topic).

> Thoughts? I am very reluctant to disturb the code path for when
> SLAPI is disabled. I think it should be possible to implement this
> without changing the code path too much (at the expense of some
> additinal code whe SLAPI is enabled).

Well, although VERY experimental, I don't think the SLAPI code
will be extraneous to the main trunk for long (as soon as somebody
will really need it :), so I'm not against rearranging code
that's not strictly SLAPI related.  Of course changes should
be general enough or worth, in terms of simplification, readability
and against code duplication, to justify them.  Maybe you can try,
if possible, to protect them behind #ifdefs (say
#ifdef STICK_WITH_GODOL_STUFF #else ...) so that we can debate
over them and try to make things as clean as possible.


Pierangelo Masarati