[Kolab-devel] IMAP resource, Kolab resource and the merged one

[Bernhard Reiter]

Hi Till, 
thanks for the nice writeup.

I still would like a way to completely switch off old style Kolab1
storage in a set of binaries, but if I understand you correctly,
this is technically not a nice solution because the code is so close
to each other.




On Thursday 16 December 2004 12:24, Till Adam wrote:
> as some of you know, I've added support for the old ical/vcard storage
> format to the new kolab resource in cvs HEAD and renamed it back to "imap
> resource", which means that it completely replaces the old "imap resource"
> (kolab1, ical/vcard style). This poses an interesting problem with respect
> to upgrade paths for the different groups of users and means we need to
> decide how to proceed for each of these. I'll try to summarize the three
> cases I see:

> 3) current kolab2 (proko2 branch) users
> Folks currently running proko2 branch are using the "kolab resource" which
> only does the xml format. Since those users don't have an upgrade path (at
> least in the context of proko2), that's fine for them, they are supposed to
> be new installations. 

We need to think about an upgrade path to future KDE releases
that have a full client compatibility.
The question would be if there is another way to make that switch,
e.g. if on an upgrade the new Kontact would just switch those resources
or run a tool for this.

Thinking about the name: Can't we offer two resources
called "dimap kolab1" and  "dimap kolab2"?

I am unsure of "imap resource" catches this best.
Basically I want that the first group can just continue using kolab1 storage
and everybody else moves to kolab2 storage
with the possibility for rare cases to add an extra resources
that can deal with old servers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2145 bytes
Desc: signature
URL: <http://lists.kolab.org/pipermail/devel/attachments/20050107/1b61a5db/attachment.p7s>