Storing complex data as folder annotations

Alain Abbas 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 
>>> (this
>>> > is my case with zpush ) ?
>>>
>>> indeed I did not consider the ACL problem. This completely 
>>> invalidates  
>>> 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 
>>> using  
>>> 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 
> annotations?
>
>>
>>> 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
>> clients?
>
> 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
Alain
> Cheers,
>
> Gunnar
>
>>
>> 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
>>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
>   




More information about the format mailing list