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

[Bernhard Reiter]

On Friday 26 November 2004 16:26, Till Adam wrote:
> 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.

Sounds fine.
Actually: How much work would it be to fix the bugs for this in proko2 branch?
The merge sounds fine for sure, but I fear that it might take a while
until we have that in proko2 branch again and maybe a quick fix can help
in the meantime.
(Would enable "imap" resource have helped me?)

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

Sounds good.

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

I want to be able lto install an configure a Kolab client
that has not legacy support and does not carry the code
(leading to less error reports and smaller software).
If the code is so much overlapping this probably is not a huge
concern as not much code can be saved when configuring it
without that legacy resource.

> > > - 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 guess migration is a different thing to allowing two different formats
in one folder. We already to permissions on a folder basis.
I really like the simple rule: Only one kind of storage format, 
one type of stored objects and one ACL per folder.

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

Per folder would be great, but allowing mixed folders seems a bad 
idea to me.
-------------- 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/20041130/9cfb5df1/attachment.p7s>