Thank you. On Aug 12, 2009, at 9:11 PM, Charlie Wood wrote:
> > 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 -~----------~----~----~----~------~----~------~--~---
