[Kolab-devel] Enhancing Kolab decision making(re: Is it okay to commit the samba patch to cvs?)

[Richard Bos]

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 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.  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.

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.

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.

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, 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.