[Date Prev][Date Next]
Re: ITS#3781 back-config doesn't work with xxx
> email@example.com 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...
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497