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

[Alain Spineux]

On Tue, Sep 16, 2008 at 9:32 PM, Richard Bos <ml at radoeka.nl> wrote:
> 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.

Any already working program is better than any nice idea to come :-)

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

Add and maintain a plugins interface seem to be more acceptable to the
Kolab's team than add a Samba patch. The plugin structure looks more
realistic from Kolab's point of view.
Of course the plugin interface is not needed by the kolab's and
samba's to work together !
And the patch is already available. Congratulation !

If I was a kolab's core developer I would have rejected the Samba patch, but
would have encouraged it as a product manager.

>
> Let's see what difficulties we run into if the samba patch would be made a
> plugin:

You expose some technical difficulties, I try to give a way to solve them !

>
> The patch provides a template file (samba.php.template.in).  So it needs to be
> build.

Build it at plugin installation time, using variable available in
kolab.conf and kolab.global

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

squirrelmail is mostly made of plugins !
Any plugin live in a subdirectory in /kolab/share/squirrelmail/plugins/
in this directory you find a least one file called setup.php that is
called by the main
squirellmail code and that add "hooks" to the squirrelmail core

Here is a small part of /kolab/share/squirrelmail/plugins/check_quota/setup.php

function squirrelmail_plugin_init_check_quota()
{
  global $squirrelmail_plugin_hooks;
  $squirrelmail_plugin_hooks['left_main_before']['check_quota']
    = 'check_quota_graph_before_do';
....

This will ask squirellmail to call check_quota_graph_before_do when drawing
part of the left panel.  check_quota_graph_before_do will generate
HTML code required to draw the "quota" bare

That's the idea for php extension

>
> Next is the slapd.conf.template; 2 schema's have to be included, some indexing

The plugins can add samba.schema into /kolab/etc/openldap/schema and insert line

include /kolab/etc/openldap/schema/horde.schema

into the slapd.conf.template file  at install time

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

The RTC could help

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

use of conf.d directory is a nice solution

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

With my, this is now 4ct.

Regards.

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



-- 
Alain Spineux
aspineux gmail com
May the sources be with you