Storing complex data as folder annotations
alain.abbas at libertech.fr
Wed Jun 9 21:24:34 CEST 2010
Gunnar Wrobel a écrit :
> Quoting Bernhard Reiter <bernhard at intevation.de>:
>> Hi Alain, Hi Gunnar,
>> thanks for starting the discussion (again) and making proposals.
>> Somehow I consider this a hard problem, which makes it a pain point
>> for me.
>> I wonder how we could go forward here. I guess it would require a
>> meeting over
>> one or two days to get this really sorted out and some hard thinking.
>> Am Montag, 12. April 2010 18:13:20 schrieb Gunnar Wrobel:
>>> Quoting Alain Abbas <alain.abbas at libertech.fr>:
>>> > well but for the folders where the user doesn t have write rights
>>> > is my case with zpush ) ?
>>> indeed I did not consider the ACL problem. This completely
>>> my suggestion. The fact that it is necessary to allow users to store
>>> configuration data on folders that they have no other right than
>>> "lookup" does however mean that there is really no other choice than
>>> using the annotation system. Any other IMAP based solution that comes
>>> to my mind and that would allow this seems even more broken than
>>> IMAP METADATA to me.
>> The main arguments against only using annotations still hold:
>> * some servers do not have them, why shouldwe exclude those servers?
> Neither the patch for Cyrus nor for Dovecot is really huge. So I think
> it is always feasible to modify a server so that it supports
> annotations. This is not the only feature the Kolab server requires
> after all. And I expect that integrating the Kolab server with a new
> IMAP server will always require a reasonable amount of effort. And
> annotations will only be a part of that. So I'd don't think this is a
> major blocker.
>> * space limitations on annotations
> I admit that I still consider annotations to be meant to contain only
> short strings. And whereever possible we should probably try to limit
> the use of annotations to short strings. In all situations where we
> would like to store more data we could try to impose additional format
> restrictions to keep the string lengths limited. Take activesync for
> an example: We could limit users to a maximum of ten devices. Not
> wonderful but maybe a reasonable compromise.
>> I am also concerned with the different types of configuration values
>> a) shared by several users
> Non-private annotations.
>> b) shared by several clients of one user
> Private annotations.
>> c) local for one client instance of a user.
> Private annotations with a format definition that allows for several
> client-specific entries.
>> Note that a client can have several accounts configured and users
>> would want a
>> good way to backup that configuration data.
> It is not ideal in many regards and I'm certainly not perfectly happy
> about using annotations this way.
> However I was opposed to this before and changed my mind because I
> didn't see a decent alternative to storing data for a folder that you
> only have read access to. The ACLs for annotations allow for such a
> scenario though.
> Do we have anything we know that we really can't solve by using
>>> So that would leave complex data in the annotations. However I would
>>> not like to use PHP serialization there. I think JSON would be more
>>> appropriate as it is not bound to a specific language.
>> Given that we also need XML because of the storage format, why not
>> use XML?
>> It might be a bit more verbose, but it would save one format parser
>> in the
> Because it is much more verbose and I still believe be we should not
> consider annotations to be a general purpose data dump. But I agree
> that having a single format type also makes sense. Probably it would
> be possible to condense the XML... hm, yeah, probably you are right.
JSON take less ressource to parse than a XML file. Json is standardized
and common and native for a lor of of languages
and less verbose yes
The code is very simple to parse it because native functions
>> Managing Director - Owner: www.intevation.net (Free Software
>> 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
> Kolab-format mailing list
> Kolab-format at kolab.org
More information about the format