On Wednesday 14 January 2009 04:23:38 Malota, Andrew Rinn wrote:
> Awhile back Dr. Gow gave me the sad news that syncing phone numbers with
> opensync .36 was busted due to: http://www.opensync.org/ticket/675
> basically that vformat conversion in opensync is busted
>
> What would be required to patch synce to "make reasonable guesses" about
> the type of the numbers when shipping them out to airsync? I ask because
> the opensync ticket seems to have been deferred again to a later release,
> and it sure would be nice to have phone number sync support, even if it is
> {hobbled, requires a patch, qwirky, unsupported, etc etc}.
>
> Has such a patch already been created?
I initially did just this: i.e. make reasonable guesses. However I was
concerned about the sync loop making irreversible changes to the structure of
user's contact data. Consider this: If syncing makes a 'guess' there is a
likelihood of data loss if two Opensync XML phone number stanzas contain
different numbers but can not be distinguished from each other. This 'error'
then gets propagated through to the other side of the sync, gets changed, then
gets propagated back again. Result: lost data (unacceptable in my opinion).
One could check the phone numbers on the Opensync side, and isolate different
numbers in different fields - but then how do you know which Airsync fields to
sync them back to? And then, when going back to Opensync, you can not separate
the fields because the XML stanzas are the same! Meaning that there is no way
to store two distinct numbers when going Airsync=>Opensync.
The code would be quite complex if it worked at all, and would only have to be
stripped out again once Opensync finally fix up vformat.
As Opensync 0.2x works, is stable and should sync phone numbers, I thought it
preferable to promote Opensync 0.2x for production work. Even Opensync suggest
that Opensync 0.3x is still experimental. So to write a load of complex code
only to have to strip it out again when Opensync finally fix up vformat seems
like a waste of precious time.
I would prefer to see Opensync 0.2x work well, fixed if and where necessary,
and to implement a correct solution in the Opensync 0.3x support once vformat
is sorted. This would be preferable to inserting a complex temporary hack to
support experimental code.
John.
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
SynCE-Devel mailing list
SynCE-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/synce-devel
