[Kolab-devel] Extending Kolab

[Alain Spineux]

On Wed, Apr 23, 2008 at 12:54 PM, Bernhard Reiter
<bernhard at intevation.de> wrote:
> Hi Alain,
>
>
>  On Monday 21 April 2008 20:08, Alain Spineux wrote:
>  > I wanted the have squirrelmail plug&play with kolab.
>  > I patched the OpenPKG package and added the "kolab" option.
>  > Then I provided a patch to the kolab team to make kolab respect
>  > the usages. (handle correctly the apache.d directory and the php.ini file)
>  >
>  > That way kolab consortium don't need to maintain the squirrelmail package,
>  > and squirrelmail is very easy to install !
>
>  did we pick up that patch, btw? (What was the issue#?)

https://www.intevation.de/roundup/kolab/issue2366

>
>
>  > The same could be done with postgrey, postgrey is available under OpenPKG
>  > and very easy to integrate into kolab.
>  >
>  > Kolab team should open their software the same way squirrelmail does :
>  >  - add some PHP hooks to allow developers to add php form into to
>  > kolab interface.
>
>  If you mean the webinterface:
>  The webinterface mainly shows what is in the directory service.
>  So just putting in another form usually is not enough as this will
>  only have the credentials of the user.

the user ? The user can be a domain admin or the manger with enough right to
update the LDAP db. Also use of shell scrip and SUDO could help for more.
This is the responsibility of the plugins developer to make the
best choice and make the thinks work.

> Yes, we could add hooks where they are
>  useful. :)
>
>
>  >  - add some free attributes to the ldapschema like
>  > "kolabFreeAttribute" where  addon can store
>  > value like "postgrey:enable" or "postgrey_delay:300"
>
>  This sounds like abusing the directory service a bit.

Yes this is a HACK !

>  If you are happy to add something, why not add real attributes to your ldap
>  scheme. I believe the hard part here is to grok the involved technologies
>  (LDAP is a beast, IMO).

Extend the ldap schema is not easy for non experimented user.
Also register new attribute or object OID is even more difficult.

But the plugin developer is free to define its own attributes or not.
Likewise The kolab team can help him for a better integration, providing
him dedicated attribute from inside the kolab OIDs.

>
>
>  > OpenPKG team is very reactive and open to new features.
>  > The kolab consortium is a lot more slow to take benefit of the user's
>  > contributions.
>
>  I guess that is true to some extend.
>  We do provide a higher level of stability and support, though,
>  which partly accounts for higher resistance to add too many features.
>  Each feature would need to go through testing and we would need to do the
>  support for it.
>
>  We have managed to raise the number of hours spend on e.g. Kolab Server
>  maintenance significantly in the last year or so. It was worse before.
>  Otherwise we are not as reactive as we would like to be, there usually is
>  a pile of things to do and we would love more help with it.
>
>  Alain, I appreciate your insight.
>

We are all living in the same world, trying to make things better and quicker.

Regards.
>
>
>  Bernhard
>
>  --
>  Managing Director - Owner: www.intevation.net       (Free Software Company)
>  Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
>  Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
>  Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>
> _______________________________________________
>  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