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

[Till Adam]

On Tuesday 30 November 2004 16:20, Bernhard Reiter wrote:
> 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?)

I'm mostly done with this, it'll go into head maybe tonight or Thursday, at 
the latest. I think it does not make sense for todays packages, but the next 
set of packages could have it, which if I understand things correctly would 
give us a few weeks to look for regression? As for quick fixes:

542 can only be resolved by allowing both formats in the resource, currently 
you would have to configure two resources, an imap and a kolab one. The 
decision which writable is then dependent on the config switch in KMail. This 
doesn't make much sense, which is one of the reasons why one resource with 
configurable per folder format is the way to go, I think.

543 is actually unrelated to this, it seems. Don't know why I listed that.

225 is basically the same issue as 542, but more general. You can enable both 
resources in parallel, but they were never meant to interoperate nor tested 
in such a setup, I believe.

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

Right. The overhead does not warrant a separate resource, in my opinion.

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

Ok, I've come to the same conclusion on further contemplation of the issue. It 
will be a per folder setting.

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

Ok.

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/20041130/beb48b1d/attachment.sig>