[Kolab-devel] MetaData for zpush Kolab backend

Gunnar Wrobel wrobel at pardus.de
Wed Jun 9 19:47:16 CEST 2010


Quoting Alain Abbas <alain.abbas at libertech.fr>:

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

Thanks. I adapted the configuration frontend for the Kolab webclient  
and it cooperated well with your annotation tools from the Kolab_Zpush  
package.

I added a "setsyncdevice.php" script that I used during testing. Hope  
that was okay. The webclient with the configuration frontend can be  
built from Kolab CV>S now.

Cheers,

Gunnar

>
> 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
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
______ 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/20100609/48abf69a/attachment.sig>


More information about the devel mailing list