[Kolab-devel] zpush: name of the annotation

[Alain Abbas]

Le 25 mars 2010 à 15:09, Bernhard Reiter <bernhard at intevation.de> a  
écrit :

> [Just to indicate that there is a discussion going on for adding  
> another
> annotation, I am sending a copy to kolab-format at . ]
>
> Am Dienstag, 23. März 2010 09:09:06 schrieb Georg C. F. Greve:
>> Hence so far I'm still in favor of
>>
>>         /vendor/kolab/activesync
>>
>> as the name for the extended IMAP annotation, which could be re- 
>> used in
>> case someone else (Horde?) came up with another activesync  
>> implementation,
>> but won't taint the namespaces for other potential syncronisation
>> protocols.
>
> Okay, we need to put mobile device configuration on the server,
> because activesync does not allow to offer the clients a way to  
> transfer a few
> settings. (If it would we could save the configuration on the device  
> which is
> something I would conceptually prefer.)
>
> Any mechanism we invent to do so, should be as generic as possible
> to maximise its use.
>
> Because this is a limitation of activesync, the suggestion is to
> use "activesync" as name for a IMAP folder annotation and to save  
> within each
> folder if it should be synced for a number of different devices.
> This indication does not seem to be useful in general as
> another sync method, let us call it betasync, might not need such a
> limitation.
> So up to now I am okay with using "activesync" as the name of the  
> annotation.
> I think it is okay to use an annotation, because this configuration  
> needs to
> be per user on all folders, including the ones that are read-only.  
> An IMAP
> server already has something similiar with the \seen flag, so it  
> will be
> doable. Using something else like a special IMAP object will pose  
> problems
> with doing this per user, e.g. because of the read-only support or  
> it will be
> farer away from the folder.
>
> Am Mittwoch, 17. März 2010 09:04:35 schrieb Georg C. F. Greve:
>>                <BOOL>[;<SERIAL NO>:<BOOL>[;<SERIAL NO>:<BOOL>[...]]]
>>
>>        with <BOOL> = 1 or 0 (for yes or no)
>>        and <SERIAL NO> = serial number of the phone
>>
>> to allow a per-device setting of synchronisation preferences.
>
> Because the default will be to not sync a device, I think we can do  
> this in a
> simpler way like:
>
>   {$udid} *{<SPACE> {$udid}}
>
seems to be a php serialization ? isnt it ?
where is the value for the uid?
could be 1 0

the default fot INBOX Could be yes by defaut and if we have the sid  
with 0 for a folder we doesn t sync it
and the inverse for shared and user namespace
in that way
with nothing in annotation the device has just INBOX FOLDERs , like  
that without any setting the user would have their things on the device
and if he would have specials things like shared or other he could set  
it

alain
> where $udid is a unique device id not containing spaces,
> which is similar to how entries are separated
> in  /vendor/kolab/pxfb-readable-for
> see
> http://ftp.intevation.de/users/bernhard/scratch/extended-freebusy-concept-0.92%2Bdev20080503-ber1-pub2.pdf
>
> In order to make device numbers unique we could propose prefixes in  
> the kolab
> space like "iphone-" or backendspecifics like "zpush12-".
> So it would be come "iphone-123456" if we are sure that 123456 is a  
> unique
> iphone number.
>
> So an entry like "iphone-123 iphone-789"
> would mean the devices 123 and 789 would be synced with this folder,  
> all
> others would not.
>
not ok with that , it is improbable , impossible that the same user  
has 2 mobiles with the same serial number.
other think , i get the serial number of the device if we add a part  
in the serial number how the bakend could know witch device it is ????


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