[Kolab-devel] annotations patch in c-client what is the status?

Martin Konold martin.konold at erfrakon.de
Fri Jun 5 07:02:34 CEST 2009


On Friday 05 June 2009 00:09:02 Richard Bos wrote:

Hi Richard,

> Op donderdag 04 juni 2009 22:26:27 schreef Martin Konold:
> > On Thursday 04 June 2009 21:27:40 Richard Bos wrote:
> >
> > Hi Richard,
> >
> > >  If so, is the kolab project (actually
> > > the companies behind the project) willing to provide funding for the
> > > c-client library?
> >
> > I see no point in helping panda in any way beyond providing patches. They
> > seem to try to blackmail their users. IMHO a very bad strategy I am not
> > going to suppport. The dynamics in the c-client library was simply not
> > there during the last years.
> >
> > I popose to make another fork of the original c-client library and
> > maintain it within kolab.org publically.
>
> But how do you convince distributions to use this fork?  If the
> distributions will stick to the original one, the situation is not improved
> on the contrary it will be confusing.

Firstly they must know about the existance of the fork.

Secondly they must know that there is NO risk involved in taking our version 
of the c-client library. (Our versions only extents the original version, is 
extremly well tested and is maintained without blackmailing so actually the 
risks are decreasing)

Thirdls they must be made aware of the differences:

 - maintained versus unmainained
 - freely available versus blackmail
 - rfc compliant features versus lack of features
 - security fixes versus blackmail

> > In the long run the c-client library will not survive anyway.
>
> Can you elaborate on this a bit more?

The codebase was stagnant for many years and is outdated. It lacks imap 
features and nobody is investing heavily in implementing the most recent IMAP 
rfcs (e.g. condstore....)

> How long is your run, if that will take years, it is not a good situation
> either.  

You mean the time until c-client dies? This will definetely take years.

> Is it not possible to
> deliver this solution faster, so it can be used now?

The fast solution is to fork now and make it widely know.

Yours,
-- martin

-- 
e r f r a k o n
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker
Sitz: Adolfstraße 23, 70469 Stuttgart, Partnerschaftsregister Stuttgart PR 126
http://www.erfrakon.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/devel/attachments/20090605/5e5e7b59/attachment.html>


More information about the devel mailing list