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

[Martin Konold]

Hi,

I think that the following message is of interest to a lot of Kolab users.

Subject: [Kolab-devel] IMAP resource, Kolab resource and the merged one
Date: Donnerstag, 16. Dezember 2004 12:24
From: Till Adam <adam at kde.org>
To: Kolab development coordination <kolab-devel at kolab.org>

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