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

[Till Adam]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Heya folks,

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:

1) "regular" KDE user upgrading from 3.3 to 3.4

For these users nothing changes. If they have been using the ical style imap 
resource the new kdepim will simply replace it and use the new version. That 
new version gives them the additional option of switching the global storage 
format preference in KMail to XML, which means that newly created folders 
will use that format. If they run the kolab2 wizard the main groupware 
folders will be set to xml format, and new events/todos/notes will be written 
to them in XML format. The new format is specified to ignore non-kolab format 
mails, so any remaining ical mails in there are no problem, they will in fact 
still appear in KOrganizer and converted on write transparently. If they run 
the kolab1 wizard, the storage format is set to ical/vcard and events and 
such are written in that format. So the resource is backwards compatible with 
kolab1 and the user does not need to adjust anything unless the server is 
upgraded, in which case it is a simple matter of changing the storage format 
default. (This scenario is the reason I did the merge in the first place, so 
that upgrading users benefit from all the fixes and improvements in the kolab 
resource which have very little to do with the format of the storage mails 
themselves.)

2) kroupware tarball users
Those are using the kroupware branch, which is for purposes of our discussion 
a KDE 3.2 with the old style imap resource. For them it would make sense to 
put the merged resource in the tarball we release for proko2 as a kroupware 
replacement as a new "imap resource", just like for scenario 1), especially 
if we expect these users to upgrade to KDE 3.4 when it comes out. That would 
mean painless migration for them as well.

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. If we now put the merged resource in proko2 and call it 
imap resource, as for the other scenarios, these users will have to remove 
the kolab resource they have currently set up and add an "imap resource" to 
get the same functionality. Re-running the kolab2 wizard would add the new 
resource for them, but they would need to remove the old kolab one manually 
(unless we extend the wizard to do that). That's suboptimal and only 
acceptable if all currently running installations are test users which can be 
expected to tolerate such a change. Doing the merge in proko2 would on the 
other hand suddenly open an upgrade path from kdepim 3.2/kroupware to proko2 
which is not bad to have if not all users can be expected to be clean 
installations. A possible solution for this group is to import the new merged 
imap resource into proko2 as a replacement for the old imap resource that is 
still in there and/or the new kolab one and either not do the renaming, or 
let the merged resource be available under both names. Not nice, though, but 
maybe acceptable.

I would appreciate your insights into this matter, especially those of you who 
are facing migrations or installations of either of these groups. My goal 
here is to make the transition as painless for as many usage scenarios as 
possible and find a packaging solution that works for everyone. (Hey, it's 
nearly Christmas, after all ;)

Thanks,

Till
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBwXCGtrsWGirveVsRAsvuAKC30nECUlqlzY/rD8AwimzN3gW7XQCeO+r4
Fqz8iNb5XvI280qWh1LHUR0=
=ND46
-----END PGP SIGNATURE-----