We'll take a look and let you know. Thanks, Charlie
On Aug 12, 8:09 pm, Paul Kasindorf <[email protected]> wrote: > Byron/Charlie, > > I've tried resyncing...logging out, logging in, replacing, resetting > iSync, etc... as recommeneded, but I still end up with (excerpt of > full sync after calendars) > : > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:26 -- *** Unknown entity: com.apple.calendars.Task > Aug 12 20:17:27 -- Added calendar event: Alberta Family Day (All day) > Aug 12 20:17:27 -- Added calendar event: Alberta Family Day (All day) > Aug 12 20:17:27 -- Added calendar event: Alberta Family Day (All > day)Aug 12 20:17:27 -- *** addSubrecordToOwners returned an error: > Error Domain=SpanningSyncErrorDomain Code=0 "Operation could not be > completed. (SpanningSyncErrorDomain error 0.)" > Aug 12 20:17:27 -- Sending data to Google... > Aug 12 20:17:32 -- ...done > Aug 12 20:17:32 -- *** The server reported failed records three times > in a row. Reverting to normal schedule. > Aug 12 20:17:32 -- Sync complete > > Any other suggestions? > > Thanks. > > Paul Kasindorf > > On Aug 12, 2009, at 5:04 PM, cwood wrote: > > > > > > > For those of you who appreciate more information, here's the note I > > just sent to Larry and Byron about the duplicate contact problem: > > > If the user had been using Address Book compatibility mode in v2.1.3, > > his data in Google had Unicode ZLS characters in it. The Spanning Sync > > 3 server code didn't properly parse that, and instead pulled it down > > as-is, which caused the client not to recognize the contact as the > > same as its counterpart in Address Book, so it created a duplicate > > (with "invisible" Unicode characters in the name and postal addresses > > at that). > > > I've now fixed the Spanning Sync 3 server code to properly parse ZLS- > > encoded names, so they're copacetic. > > > People can remove the dupes with Tools, or they can simply restore > > from the backup made when they installed Spanning Sync 3. Instructions > > for that are on the web at <http://spanningsync.com/help/#preinstall- > > restore>. > > > But wait, there's more! > > > Some time in the last two weeks, Google made an unannounced change to > > the way their Contacts API parses names. Previously, if we gave them a > > structured name (like title="Dr.", first name="Hans Peter", last > > name="Schulz"), Google would store those values in their own > > "structured" fields, and also create a "formatted" version for display > > in Google Contacts, like "Dr. Hans Peter Schulz". If however someone > > created a contact in Google Contacts, which doesn't know anything > > about structured fields yet, the record would get a formatted version > > ("Dr. Hans Peter Schulz") and the structured fields would be left > > empty. This works well, since our code can look first for the > > structured data, use it if it's there, and if not then fall back to > > parsing the formatted/unstructured data, which we do pretty well. We > > worked hard on that. > > > But then Google changed something. Now when someone enters a contact > > name in Google Contacts, Google applies their own parser to the > > formatted/unstructured name and populates the structured fields with > > the output. That's wouldn't be so bad except for the fact that their > > parser is awful. "Dr. Adam Smith" gets parsed as (first name="Dr.", > > middle name="Adam", last name="Smith"), to say nothing of multiword > > names like "von Beethoven" or suffixes like "Ph.D.". But there's no > > way for me to know if Google put the "structured" information in the > > record or if we did, so if I see it I use it. And if Google put it > > there, chances are it's going to cause a dupe unless it's a super- > > simple name like "Adam Smith". > > > So the good news is people won't see every single contact duplicated > > on their first sync after upgrading. The bad news is, until Google > > fixes their parser, people will still see dupes sometimes for contacts > > with anything other than super-simple names. The fix is easy: just > > delete the version where the names aren't in the right fields and > > sync, but it's still a pain. > > > I'm in touch with the Contacts API team and hope they can get this > > fixed soon. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Spanning Sync" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/spanningsync?hl=en -~----------~----~----~----~------~----~------~--~---
