[Kolab-devel] MetaData for zpush Kolab backend

Alain Abbas alain.abbas at libertech.fr
Sun Jun 6 17:30:39 CEST 2010


hi Gunnar
The Modifications are made and published in the SVN (Kolab_Zpush-0.1.1).

hi Christoph
be careful something are changed Kolab_Zpush-0.1.1 instead Kolab_Zpush-0.1.0
i hope that is not annoying for you but in coordination with Gunnar we 
changed a thing  that 
could be changed after .

Regards Alain

Gunnar Wrobel a écrit :
> Quoting Alain Abbas <alain.abbas at libertech.fr>:
>
>> hi
>> like advised by Gunnar we would use JSON insteed than PHP serialization
>> to serialize datas
>>
>> Alain
>>
>> ================================================================================ 
>>
>>
>>
>> Metadata for the backend Kolab Zpush
>>
>>
>> 1) storage
>>
>>    The metadatas for the kolab backend will be stored in the folder
>> annotation
>>    the entry will be :
>>    /vendor/kolab/activesync   value.priv
>>    All the annotations are per user and are private
>>    The global setting will be stored in the root folder INBOX
>>    The per folder setting will be stored in each folder
>>
>> 2) Data representation
>>
>>    The data will be stored as a serialized JSON Format with specific 
>> keys
>>    (php instruction json_encode() and json_decode() )
>>    Example :
>>    {"APPL023Z34":{"SYNC":1,"ALARM":1}}
>>    that is the serialized data :
>>    array (
>>       'APPL023Z34' =>
>>       array (
>>             'SYNC' => 1,
>>             'ALARM' => 1,
>>           ),
>>
>>            )
>>
>>
>> 3) Global data
>>
>>    The globals data will be stored directly in INBOX folder
>>
>>    $meta["DEVICE"][<SERIAL-NUMBER>]["TYPE"]="type of the mobile"
>>    $meta["DEVICE"][<SERIAL-NUMBER>]["MODE"]= -1 | 0 | 1
>>         -1 (the global mode set for the backend) (DEFAULT)
>>          0  Flat mode
>>         1  Folder mode
>>
>>
>>    Example:
>>    $meta["APPL023Z34"]["TYPE"]="iphone";
>>    $meta["APPL023Z34"]["MODE"]= -1;
>>    $meta["ANDRO099393939"]["TYPE"]="android";
>>    $meta["ANDRO099393939"]["MODE"]= 0;
>>
>>    the annotation will be :
>>
>> {"APPL023Z34":{"TYPE":"iphone","MODE":-1},"ANDRO099393939":{"TYPE":"android","MODE":0}} 
>>
>>
>>    The serials will be collected by the backend at the connexion.
>>    if the keyword MODE doesnt exist or if it s equal to -1 for a device
>> the Golbal setting will be applied
>>
>>
>> 4) per Folder Setting
>>
>>    Politic rule for the synchronization
>>    INBOX/* all the folders in this namespace  will be synchronised by
>> default, except if the parameter is set to no
>>    user/*  all folders won t be synchronised by default,  except if the
>> parameter is set to yes
>>    shared.*  same
>>
>>    The same politic will be applied for the Alarms
>>
>>    $meta[<SERIAL-NUMBER>]["SYNC"]= 0 | 1  1 the folder will be sync , 0
>> the folder won t be sync
>>    $meta[<SERIAL-NUMBER>]["ALARM"]=0 | 1  1 the Alarms will shown
>>
>>    Example:
>>    $meta["APPL023Z34"]["SYNC"]=1;
>>    $meta["APPL023Z34"]["ALARM"]= 1;
>>    $meta["ANDRO099393939"]["SYNC"]=0;
>>    $meta["ANDRO099393939"]["ALARM"]= 0;
>>
>>    the annotation will be :
>>    
>> {"APPL023Z34":{"SYNC":1,"ALARM":1},"ANDRO099393939":{"SYNC":0,"ALARM":0}} 
>>
>
> When I did my final test run on the Zpush configuration frontend for 
> Kolab Server 2.2.* I noticed that your code in kolabActivesyncData.php 
> does automatically set "SYNC=1" if "ALARM=1". This indicates that both 
> settings are copuled which I didn't notice when reading through the 
> metadata description. Are both settings indeed dependent on each other?
>
> If so it wouldn't make much sense to represent them as two separate 
> booleans. What you'd rather want is a single setting "SYNC" with three 
> different states: "0" for "do not sync", "1" for "sync without 
> alarms", and "2" for "sync with alarms". Does that make sense or is it 
> incorrect for some other reason that I did not see?
>
> Would that be something that can still be corrected? If so one could 
> also rename the name of the setting to a simple "S". I think it is 
> okay to be as brief as possible there.
>
> Cheers,
>
> Gunnar
>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Kolab-devel mailing list
>> Kolab-devel at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-devel
>>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel




More information about the devel mailing list