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 <mbarnes 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/
Attachment:
signature.asc
Description: This is a digitally signed message part.