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

Bernhard Reiter bernhard at intevation.de
Fri Nov 26 16:02:16 CET 2004


On Thursday 25 November 2004 11:45, Till Adam wrote:
> 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?
> There are several reasons why I think this is
> a good way to do this:

I think this idea is fine if other kdepim people concurr
and the kolab2 storage format functionality is not destablelized.

How much new code will it be, btw?
I consider it a downside if I cannot configure a KDE Kolab client
without legacy support code.

> Downsides:

> - 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

Policy and documentation is not enough, we need software support.
The rule: Have on storage format in one folder seems very reasonable to me.
Why not enforcing it with Kontact?

> - it will make the kolab resource slightly more complex, but that should be
>   straightforward switching over storage types, no additonal logic
-------------- 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/20041126/84dabad6/attachment.p7s>


More information about the devel mailing list