[Kolab-devel] Merging the imap resource functionality into the kolab one

[Till Adam]

Morning kolaborators,

while thinking about how to tackle 

https://intevation.de/roundup/kolab/issue543
https://intevation.de/roundup/kolab/issue542
https://intevation.de/roundup/kolab/issue225

I came up with the following idea:

What if I simply merge the ical/vcard functionality into the new resource? All 
the functionality is there, it merely needs to be able to read the ical 
instead of the xml (no problem) and skip the conversion from/to xml when 
reading and writing, depending on the mimetype, which we have available. The 
configuration switch determining the storage format could simply become a "I 
will write incidences in this format" and both formats could be read and 
processed transparently. There are several reasons why I think this is a good 
way to do this:

- we could rename the (as yet unreleased) kolab resource to imap and drop the
  old imap resource completely
- no duplication of code and functionality between imap and kolab resource
- almost no config change on the user side needed, just switch to the new 
  format in KMail and that's it
- no porting of the imap resource to the new dcop interface to unbreak it
- easier migration path, the user simply makes a new folder, called "legacy"
  or "archive", or whatever, puts all the mails in there, they continue to be
  shown, new events/contacts go to the new folder in the new format and can
  there be shared across clients as normal for kolab2. For contacts we also
  have "Store in ...", so users can simply select the contacts in the old
  folder and migrate them to the new format with a single menu click. For 
  events I don't think people will need much migrating of old events, but if 
  they do, they can cut and paste them.
- magically all the new niceties of the kolab resource are available 
  regardless of the storage format of individual events
- the kolab-xml-v2 format which might emerge at some point is just another
  switch that can easily be added

Downsides:
- we lose online imap support, which the old imap resource is partially 
  capable of. I could personally live with that, as making that really 
  work needs a few changes deeper in KMail which I am not prepared to 
  undertake at this point anyhow. It also makes the resource much more
  complex due to the async nature of online imap.
- we might need to ensure that people don't mix the formats in one folder, 
  which is a problem for OL, I believe, although not a problem at all for
  Kontact. This could and maybe should be solved via documentation, since it
  is only a problem for mixed client environments which should be able to
  enforce this via policy and migration plans
- it will make the kolab resource slightly more complex, but that should be
  straightforward switching over storage types, no additonal logic

What do you think?

Till
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20041125/2851ec51/attachment.sig>