[Kolab-devel] Enhancing Kolab decision making(re: Is it okay to commit the samba patch to cvs?)
Gunnar Wrobel
wrobel at pardus.de
Fri Sep 19 13:44:44 CEST 2008
Quoting Richard Bos <ml at radoeka.nl>:
> Hi,
>
> Op Monday 15 September 2008 23:53:59 schreef Alain Spineux:
>> Bernhard asked my advice about the inclusion of this patch in CVS .... :
>>
>> As I say for long time now, I'm more in favor of a plugin interface than
>> the inclusion of any Samba's specific code into Kolab.
>>
>> The pros and cons of the plugin architecture :
>>
>> - require more code than the simple Samba's specific patch
>> + the plugin architecture could be helpful to future Kolab's plugin
>> projects ( Asterisk integration, black and grey listing, ....)
>> + The two projects (kolab and the samba plugin) will be able to
>> evolute independently. Changes in one will not automatically implies
>> change in the other. This is true for bug too.
>>
>> For remember the Kolab's plugin interface should contains a least :
>> - some kolab's perl and PHP "function helper", "
>> - some php "hooks" to add screen and functionalities to the admin
>> interface, - some "hook" from inside the kolabd and the template generation
>> ùprocess
>
> Let me put it this way: let us know when the plugin interface is available we
> can than use it to add the samba functionality.
>
> Of course a plugin interface would be nice, but it is not here
I disagree. Any package management system is meant to be used for
extensions. Granted the OpenPKG based Kolab Server has a long history
of not enabling users to choose.
Currently the list of packages you can install when running
install-kolab.sh is fixed. No choices allowed. But that does not
change the fact that a user could generate an experimental RPM package
for the Kolab Server and distribute it. It is actually not that hard.
You could for example package a PHP web application (e.g. PHP-BB or
some other fancy stuff) and provide it to other Kolab users so they
can install it in their server. That is indeed a plugin interface.
Of course that interface is quite limited. It is mainly file based but
this is enough to reach a lot of things. You actually mention some of
these things further down and I'll comment them there.
> and I think
> that it will take a long (very long) time till it arrives. Now with regards
> to the samba patch, it is of course possible to wait till the plugin
> interface arrives or as the patch is about ready to be committed to cvs that
> could be done as well. If one waits long enough the current patch can't be
> committed anymore as the sources in cvs will have changed and a nice
> oppertunity will have passed to include some samba functionality. The kolab
> devs could of course state that the patch will be included if someone
> provides the plugin structure, hoping that e.g. Albrecht or Christian (the
> samba patch providers) will provide the plugin structure. But Albrecht e.g.
> already stated that he won't customize the patch further, so forget he'll
> provide a plugin structure...
>
> Let's see what difficulties we run into if the samba patch would be made a
> plugin:
>
> The patch provides a template file (samba.php.template.in). So it
> needs to be
> build. This makes it already much less attractive as a plain plugin.
Why? Any plugin package will have to be build using rpm. That is an
essential part of package management when using binary packages and I
don't see a problem with it.
> The
> samba.php include file much be included in the file www/admin/user/user.php.
> How should happen with a plugin structure? Should there be
> a /usr/lib/php/kolab/plugins directory? Should all the php files in that
> directory be included in the www/admin/user/user.php? Or should the plugin
> have a kind of include tag that states that it should be included in
> user.php? This is I believe still the easy part. Next is that the plugin
> should be triggered when a new user is saved, or removed and when the
> password is saved. How is that to be done? Here some smart plugin mechanism
> needs to be developed.
kolab-webadmin is really the only problem I see. More on this at the
end of the mail.
>
> Next is the slapd.conf.template; 2 schema's have to be included,
> some indexing
> keys are defined and new acl's are added. The latter can be achieved when
> kolab is going to use the new openldap configuration method (what is it
> called Real Time Configuration, I believe). The plugin openldap stuff can
> just be dumped in the RTC openldap directory. I don't believe that the
> plugin additions can be easily added to the current slapd.conf file.
Why not? I don't know at the moment if the "include" statement in
slapd.conf would allow something like "include
/etc/openldap/plugins/*.conf". If not you could still use such a
directory and have kolabconf compile the single files in
"/etc/openldap/plugins" into one file "/etc/openldap/plugins.conf"
which you include with "include /etc/openldap/plugins.conf" in
slapd.conf. Does not sound that hard to me.
>
> Last for this patch is the addition of variables to kolab.conf. This can be
> achieved when kolab is going to use a conf.d (/etc/kolab/conf.d) directory.
> Plugins could just dump their variable definitions there and kolabconf would
> read them.
Sounds pretty easy. Why shouldn't we do it this way?
>
> For the RTC slapd.conf there is already an issue. For all the other
> challenges there isn't.
>
> Perhaps issues should be opened for the ideas mentioned above (and
> that others
> agree with). But I also think it shows that the plugin interface is not
> available for a long time. Hence the samba patch should be committed to cvs
> the way it is now available,
I really don't think so. You had some very good suggestions which are
not that hard to implement and I think just fixing the
/etc/kolab/conf.d/ and the /etc/openldap/plugins/ issues would already
allow you to package the biggest part of the samba patch in a plugin.
Of course that still excludes the kolab-webadmin package and I
acknowledge that this is a problem indeed. File-based extensions are
currently not possible there.
I started rewriting the code once but I failed to get it done for time
constraints. I still believe this is a thing that is in dire need of
full rewrite.
Nevertheless: When I look at the discussion above and the good
proposals you already made, maybe finding a a simple solution for
kolab-webadmin wouldn't be that hard either? I'm certainly willing to
discuss that.
In any case thanks for fostering the discussions. Even if the whole
process is slow I believe we are getting somewhere :)
Cheers,
Gunnar
> if it is to be accepted by the kolab devs at
> all.
>
> My 2ct.
>
>
> --
> Richard Bos
> We are borrowing the world of our children,
> It is not inherited from our parents.
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
--
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 700 6245 0000 Bundesstrasse 29
Fax : +49 721 1513 52322 D-20146 Hamburg
--------------------------------------------------------------------
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
More information about the devel
mailing list