[sync] Synching Birthday-entries?

[Jan Schneider]

Zitat von Lukas Gradl <horde at ssn.at>:

>
>
> Jan Schneider schrieb:
>> Zitat von Lukas Gradl <horde at ssn.at>:
>>
>>>
>>>
>>> Jan Schneider schrieb:
>>>> Zitat von Lukas Gradl <lazarus at ssn.at>:
>>>>
>>>>>
>>>>>
>>>>> Jan Schneider schrieb:
>>>>>> Zitat von Lukas Gradl <horde at ssn.at>:
>>>>>>
>>>>>>>
>>>>>>> Jan Schneider schrieb:
>>>>>>>> Zitat von Lukas Gradl <horde at ssn.at>:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jan Schneider schrieb:
>>>>>>>>>> At the moment you can't even sync anything but your default  
>>>>>>>>>>  calendar.  When we add preferences to choose the resources  
>>>>>>>>>> to  sync with, we might  add time objects (like birthdays)  
>>>>>>>>>> too. This  might collide with clients  that already show  
>>>>>>>>>> birthdays in the  calendar, like Outlook, though you  could  
>>>>>>>>>> always turn it off, of  course.
>>>>>>>>> Thanks for your explantations.
>>>>>>>>>
>>>>>>>>> Are there any near future plans to create a possibility for   
>>>>>>>>> user-settings in SyncML?
>>>>>>>> Plans? Yes. In the works? No. Though I'll try to implement  
>>>>>>>> this for  address books this week so that I can easily take  
>>>>>>>> all my address  books on the road while on vacation. :)
>>>>>>> What I was thinking about is quite near your plans:
>>>>>>> - Choosing which addressbook(s) to sync
>>>>>>> - and making a few tests if it might be possible, that the  
>>>>>>> user can  select his type of mobile device and the  
>>>>>>> sync-process will change  field-mappings according to that  
>>>>>>> setting (and perhaps this "select  mobile device" might be a  
>>>>>>> good place to check the synched fields for  deleting  
>>>>>>> attributes as Gunnar suggested...)
>>>>>>
>>>>>> No, this is not necessary and doesn't make much sense. There  
>>>>>> are only  so many properties possible for vCard or SIF-C data.
>>>>>
>>>>> Don't understand your answer....
>>>>> - I know this is not possible at the moment - that's why I  
>>>>> wanted to make some tests if it might be possible to implement...
>>>>>
>>>>> - why does that not make sense? Nearly every mobile device has  
>>>>> different Field-Maps (eg. the telephone-numbers!) So why not  
>>>>> make a possibility to change the mappings on a per user base?  
>>>>> IMHO that makes sense!
>>>>
>>>> It doesn't matter what these devices do internally. In the end  
>>>> they have to synchronize their data with a set standard. And  
>>>> these standards (see above) only provide a fixed set of possible  
>>>> properties. We already support those (to some extend).
>>>
>>> A fixed set of possible properties? Where in which standard is a  
>>> definition of possible properties (and let alone which  
>>> "human-readable-fieldname" they get!)? There are only rule for HOW  
>>> to encode things, but not WHAT.
>>
>> Eh? vCard and SIF-C *do* specify available contact properties.
>
> RFC2426:
> Overview:
>    The profile also provides support for non-standard extensions to the
>    schema. This provides the flexibility for implementations to augment
>    the current capabilities of the profile in a standardized way.
>
> and:
> 3.8 Extended Types
>    The types defined by this document can be extended with private types
>    using the non-standard, private values mechanism defined in [RFC
>    2045]. Non-standard, private types with a name starting with "X-" may
>    be defined bilaterally between two cooperating agents without outside
>    registration or standardization.

Okay, partly convince, but a) this still doesn't hold for SIF-C data,  
and b) we still need to know what it means if a client sends a certain  
extension. And where we already know this, we map them, like the  
X-SYNCJE-* properties in Turba.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/