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

[Gunnar Wrobel]

Quoting "Georg C. F. Greve" <greve at kolabsys.com>:

> On Monday 22 March 2010 13:15:22 Bernhard Reiter wrote:
>> While the protocol is activesync, I wonder if using a more generic name
>> would be have an advantage.
>
> Other protocols would likely want to store different metadata, or at least in
> different format. Since we would then be in a namespace conflict, this seemed
> like the right abstraction level.
>
>
>> We possibly have to make this more complicated.
>> Note that anyone could just give you an ACL on a folder, so if the default
>> is "yes", this means I can just spam your appointments by giving you a
>>  folder that immedeately gets synced. So a default of NO seems to be the
>>  better solution. Or something like YES for folders where in my personal
>>  namespace and NO for all others.
>
> Agreed.
>
>
>> Is the serial number unique?
>
> AFAWK, Yes.
>
>
>> If I think about having two or more devices, is there a way to make that a
>> client configuration option?
>
> The current configuration layout allows to have as many devices as you want,
> and individually set your synchronisation preferences for each of them.
>
>
>> Arg, this brings me back to the much debated question of where should
>>  client configuration go so. We never had a good conclusion on this one as
>>  far as I remember.
>
> There are two places where this information can logically go: LDAP & IMAP.

Correct.

>
> LDAP has been excluded for a wide variety of reasons which Thomas and Sascha
> can highlight again if you feel the need to go through the motions one more
> time.

+1


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

For small configuration values as you describe them the approach may  
work. So I'm not saying we shouldn't use this approach for Z-Push now.  
It might be difficult to find a common ground concerning the  
configuration format in time for the desired delivery date for a  
working Z-Push solution on the Kolab server.

The main problem I see with using annotations is the fact that they  
are not meant to be used as a generic data storage element. The have a  
fixed string length. So once you start storing data such as

<BOOL>[;<SERIAL NO>:<BOOL>[;<SERIAL NO>:<BOOL>[...]]]

this hits a limit at some point. Concerning ActiveSync this might play  
no role as you can probably still store hundreds of devices in the  
annotation.

But from the purist point of view I would say it smells :)

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.

Cheers,

Gunnar

>
> Best regards,
> Georg
>
> --
> Georg C. F. Greve
> Chief Executive Officer
>
> Kolab Systems AG
> Zürich, Switzerland
>
> e: greve at kolabsys.com
> t: +41 78 904 43 33
> w: http://kolabsys.com
>
> pgp: 86574ACA Georg C. F. Greve
>



-- 
______ 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/20100322/172044e7/attachment.sig>