Hi all, Am Montag 19 August 2013, um 17:47:07 schrieb Srinivasa Ragavan: > On Mon, Aug 19, 2013 at 9:03 PM, Matthew Barnes <mbar...@redhat.com> wrote: > > The IMAPX classes were moved into Camel's public API to serve as base > > classes for evolution-kolab. But since Christian has parted ways with > > us it would appear the evolution-kolab project is no longer active.
Sorry for being silent for so long. I was hoping to catch up on schedule
with evolution-kolab again, but so far, I have not managed to do so because
of being highly loaded with other projects (and evolution-kolab being a
spare time project at present, with, alas, no more funding, and very low
spare time anyway).
As far as Kolab goes, the Kolab people have released a new major version 3,
which has the XML storage format changed over the Kolab format version 2,
which evolution-kolab currently supports.
This would mean to implement a new storage format conversion library for
evolution-kolab, which we had planned, but due to budget issues, were not
able to implement.
> > I'm planning a good deal of API changes to IMAPX over the next few
> > months as I work toward completing IMAP NOTIFY support, and I would
> > prefer these changes not be seen as breaking Camel's public API so I
> > have sufficient freedom to change what needs changed.
The IMAPX had been exposed so it could be subclassed and enhanced
by evolution-kolab for IMAP-ANNOTATE (Kolab3 uses IMAP-METADATA).
In 3.4 times, we had an IMAPX code copy within the evolution-kolab
code base, which we got rid of by making IMAPX a Camel public API,
so we could subclass it.
> > Therefore I plan to move the IMAPX classes back to a runtime-loadable
> > module library after the 3.10 release. If the evolution-kolab project
> > is resurrected at some point in the future then we can renegotiate this.
If by that time, upstream IMAPX can be extended with the aforementioned
IMAP extensions, then no need to publicly expose IMAPX again, I guess.
> > Any objections?
*sigh* Honestly, I cannot really object here, since I do not know when
(or even, if) I will be able to resurrect evolution-kolab. From what I can
tell reading through the Kolab3 devel list posts, this version of this
groupware server seems to catch on better than the previous version did,
since they *finally* decided to drop the old OpenPKG distribution format
alltogether with Kolab3 and started packaging for distributions. There is,
also, still a great need for Kolab clients, although I have not been approached
in that regard after evolution-kolab went on a hiatus.
> I still dont accept it under Camel. Since we are fixing it, Im fine.
> -Srini.
Srini, do I get you right in that you do not accept a certain IMAP
implementation
(IMAPX in this case) being exposed by Camel? I do agree that it somewhat breaks
the idea of Camel, that the actual IMAP implementation which gets used should be
hidden.
When it comes to IMAP extensions, then this concept is somewhat difficult
in that it restricts what a certain IMAP implementation can expose feature-wise,
and there are some IMAP extensions (like ANNOTATION or, more recently,
METADATA),
which may make sense to be implemented by, say, IMAPX, but maybe not in any
other
IMAP code within Camel.
evolution-kolab could always resort back to keeping around its own copy of
IMAPX, although this would be a nightmare to keep up-to-date.
Cheers! I hope to be around more often again in future.
Christian
--
kernel concepts GmbH Tel: +49-271-771091-11
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
