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

[Till Adam]

On Friday 26 November 2004 16:02, Bernhard Reiter wrote:
> 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.

I believe they do concur. As far as destabilizing goes, this'll be done in 
HEAD first and tested there. Backporting to proko2 can then be considered 
separately.

> How much new code will it be, btw?

It won't be much code. The kolab and imap resources have a large overlap in 
code and functionality. The kolab one has seen a lot more love these last 
months, though, so the imap one severely lacking in comparison.

> I consider it a downside if I cannot configure a KDE Kolab client
> without legacy support code.

I don't understand this sentence, can you please elaborate?

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

The idea was to allow migration between the formats without the need to create 
new folders. I think neither the current OL connector nor Kontact nor Horde 
should have a problem with non-kolab/xml mails in resource folders, since the 
new format allows that, but maybe the old connector does not like the xml 
mails mixed among the ical ones it expects, so in that case we would indeed 
need to enforce it. There is also the scenario of someone wanting to use a 
kolab2 server along side an imap only resource on another folder. Then the 
writing format could not be global either and would have to be per folder 
anyhow. So it looks like we might need that indeed, at least configureably.

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/20041126/3704126e/attachment.sig>