[sync] Re: SyncML update [PATCH]

[Johny]

Elegant solution, makes it easy to extend the API as new types and minor
variations on types are discovered with new devices!

Ta for the info :)

:)J

> Anthony Mills wrote:
> 
>> We are going to use the 'registry' APIs to look up import and export 
>> functions.  Something like registry[$localuri]->import($content, 
>> $contenttype).  In the case of vcards, $localuri = 'contacts', 
>> $content = (vcard data), $contenttype = 'text/v-card'.  localuri, 
>> content, contenttype are all parsed out of the SyncML packet.  This 
>> way, one-way, two-way, etc sync types will work for all content types 
>> that we support.  It also means that if the server supports 'contacts' 
>> it will support 'todos' and any other types, as long as there is aare 
>> APIs between for $localuri.
>>
>> I guessed that the P800 did not use WBXML, but I wanted to see the 
>> tags it used, to make sure I understood what you were seeing.
>> Anthony
>>
>> johny at agotnes.com wrote:
>>
>>> no probs :)
>>>
>>> Having looked at the detail records in the past using a test harness 
>>> server I
>>> did actually know it doesn't use WBXML, sorry, should've said!
>>>
>>> The 'issue' is, it passes VCARDS up to the server, are you intending 
>>> to make
>>> VCARD parsing an integral part of the solution (or indeed, have you 
>>> already got
>>> something for it that I've yet to spot?)
>>>
>>> Cheers,
>>>
>>> :)J
>>>
>>> Quoting Anthony Mills <amills at gascard.net>:
>>>
>>>  
>>>
>>>> Thank you for sending the header.  It should be fine.  It is almost 
>>>> the same as the syncml clients I use, weblicon(sp), and 
>>>> synthesis(sp?).  You don't need WBXML, which is good.  All your 
>>>> calls are going to go to syncml.php in framework/RPC/RPC.
>>>>
>>>> Thanks,
>>>>
>>>> Anthony
>>>>
>>>>   
>>>
>>>
>>>
>>>
>>>  
>>>
>