[Kolab-devel] Completing ActiveSync integration in Kolab, and a request for input on IMAP annotatemore extensions

[Gunnar Wrobel]

Quoting Bernhard Reiter <bernhard at intevation.de>:

> Am Montag, 22. März 2010 16:32:29 schrieb Georg C. F. Greve:
>> On Monday 22 March 2010 14:28:20 Gunnar Wrobel wrote:
>> > > That is why the conclusion has been to put this into a private extended
>> > > annotation.
>> >
>> > Concerning IMAP the annotations are of course not the only storage
>> > space available. I would consider the folder contents to be a much
>> > more appropriate storage space.
>>
>> Ah, yes.
>>
>> Configuration management & storage in Kolab for third party integration.
>
> This has been a long debate for a while, because there are not a lot IMAP
> servers out there that implement annotations in full bloom. So if you just
> have an imap server, it is harder to use as Kolab Calender folder.
> Using a special object would change that.
>
> Also the question is: One person has several clients (all Kolab clients)
> and would want to keep parts of the configuration for some of them and some
> for all of them. How should Kolab model that in the future.
> Doing special objects in the folder would be one way, but this does not solve
> all problems. Especially it is not clear where the configuration for
> clients * folder shall go to.
> The Cyrus people experimented with a few more protocols in addition to IMAP,
> but gave up on that.
>
>> > As we are adding the second annotation of this type now I feel we
>> > should indeed tackle the configuration topic again in the near future.
>
> I think we either have more annotations like this or it is the first.
> So which one are you thinking about?

We also store a potentially unlimited list of elements in the  
pxfb-readable-for annotation. We discussed the very same problem when  
we implemented the xfb concept as I had the same concerns then.

Cheers,

Gunnar

>
>> Agreed. We might want to start collecting thoughts on this soon.
>>
>> For the moment however we should think about how to make the extended
>> annotation storage work reliably as expected. Help for this would be most
>> appreciated.
>
> Given the change of implementations on the server side we probably need to
> evaluate what we want to do on the client side. Another topic for
> kolab-format@ IMO.
>
> Bernhard
>
>
>
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20100323/401920a7/attachment.sig>