[Kolab-devel] Extending Kolab

[Alain Spineux]

On Wed, Apr 16, 2008 at 9:47 AM, Gunnar Wrobel <wrobel at pardus.de> wrote:
> Bernhard Reiter <bernhard at intevation.de> writes:
>
>  > On Thursday 03 April 2008 08:57, Gunnar Wrobel wrote:
>  >> > I would maintain that Kolab Server is already pretty "pluggable" due to
>  >> > its Unix philosophy.
>  >>
>  >> Of course any free software can be extended. The relvant question in
>  >> that context is how much energy it costs the user to actually do
>  >> that. Usually the free software project itself can try to lower the
>  >> initial hurdles.
>  >
>  > I agree with the general point. My thesis is that Kolab Server already
>  > makes it comparatively easy because of its design philosophy
>  > to add additional components.
>  > Your point - as I understand it - is more about how to extend
>  > the server or its package itself. This is different from being prepared
>  > to plug in more stuff.
>  >
>  >> For the Kolab-Server project I believe we have some dificulties in
>  >> making it easy to add stuff like munin or greylisting. Adding such
>  >> extensions would in principle just require adding some configuration
>  >> files. As such it would be easy to do.
>  >
>  > I am unsure how difficult it really is to add greylisting to a Kolab Server
>  > installation. We could have more documentation for frequent cases and I
>  > believe the wiki helps in this regard.
>  >
>  >> But it is far from trivial for a user that would like to contribute
>  >> back to actually get this added into the Kolab-Server so that other
>  >> users can test/use this too.
>  >
>  > Getting it into the main distribution and should it be in there
>  > is often a hard question. In the following you are talking about
>  > this integration in the core server distribution. There are other
>  > ways to make it easy for others to try things out.
>  >
>  >> I see at least three problems there:
>  >>
>  >>  - You'll have to ensure the stuff works on OpenPKG
>  >>
>  >>  - You'll have to find a developer to actually care for the addition
>  >>    so that it finds it way into the CVS system. That is extremely hard
>  >>    as deleoper time is rare.
>  >>
>  >>  - The Kolab-Konsortium needs to support the extension which usually
>  >>    means that it gets a good deal of testing so that customers don't
>  >>    come back complaining that things don't work.
>  >
>  > All those are very reasonable criteria before something gets
>  > into the main distribution. Especially maintenance and compliance
>  > with the rest of the system is critical or we will face a quality problem
>  > pretty soon. Kolab Server lives from real world implementations which
>  > have high requirements for those topics.
>  >
>  >> So in fact adding things like greylisting or munin or something else
>  >> is pretty hard with the Kolab-Server at the moment. At least if it is
>  >> something a user would like to share with the community and not just
>  >> keep for himself.

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 !

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.
 - add some free attributes to the ldapschema like
"kolabFreeAttribute" where  addon can store
value like "postgrey:enable" or "postgrey_delay:300"


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.

Regards.

>  >
>  > I suggest to go a different route, e.g.
>  > a) do a good maintained documentation
>  > b) we create add-ons for which we can lower the quality criteria
>
>  Point b) was what I was aiming at.
>
>  Cheers,
>
>  Gunnar
>
>  >
>  > Best,
>  > 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
>
>  --
>  ______ http://kdab.com _______________ http://kolab-konsortium.com _
>
>  p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
>
>  ____ 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 <<
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>  _______________________________________________
>  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