[sync] Synching Birthday-entries?

[Lukas Gradl]

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.


regards
Lukas
-- 

----------------------------
software security networks
Lukas Gradl <horde#ssn.at>
Eduard-Bodem-Gasse 9
A - 6020 Innsbruck
Tel: +43-720-300168-0
Fax: +43-720-300168-21
----------------------------