Re: ITS#3781 back-config doesn't work with xxx

[ando@sys-net.it]

> ando@sys-net.it wrote:
>>> Is there a description somewhere of what it means to support
>>> back-config?  For example, how would back-perl do it?  The admin can
>>> write a Perl config() function which defines new slapd.conf directives;
>>> only a few directives are hardcoded.
>>>
>>
>> I suggest that backends like back-perl just define a "perl-" directive
>> that allows arbitrary length and args which are passed to the
>> user-provided config routine.  I see it a bit harder to implement "emit"
>> in a consistent way, though.
>>
> That implies that you'll only have a single attributeType for back-perl
> config directives. I guess it would work, but it pretty much means
> implementing a table-driven config engine in perl, to manage things from
> there (assuming you want to support LDAP_MOD_DELETE and have full
> runtime reconfigurability). Or maybe a set of perl hooks for
> constructing schema tables that can be passed to
> config_register_schema(), so that the perl module can properly define
> its config items. I think either way this is a fair chunk of perl XS code.

I don't see much alternative, though.  The other way 'round, back-perl
should provide APIs to register from PERL new attributeTypes at the
back-perl level; those args should stick with "standard" handlers,
otherwise custom handlers would require back-config to invoke a wrapper
that calls some PERL hook that does handling.  It can be done (and I'm
sure 99% of the custom args would be fine with standard handlers, like
register an integer or copy a string.  But I don't see much added value in
having something that by nature should be experimental supported in
back-config.  Unless you intend to entirely remove the slapd.conf
interface at some point...

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497