That is an interesting thought, Alain. The one downside that I can see is that unlike the etags, when a contact record changes, the extended property will not change automatically, so I can't discern a modified contact by looking at the extended property.
On Tue, Nov 22, 2011 at 12:14 PM, Alain Vongsouvanh <[email protected]>wrote: > Hello, > > Etags are indeed read-only and generated by the API. You can however use > extendedProperties which are not visible in the Contacts Manager web UI (in > GMail) and can be used by client applications to store custom data. > Please be aware that those properties are available to every client > applications accessing Contacts data through the API. > > Best, > Alain > > On Sun, Nov 20, 2011 at 9:11 AM, David Rodrigues > <[email protected]>wrote: > >> Thanks for the reply. I *think* etags are read-only. (If I am wrong, can >> someone let me know?) In other words, I can't create an etag with some >> specific numbering convention (say, based on the date and time), then look >> to see if it has changed. However, I am giving up on the idea of not saving >> any stateful information between syncs. So I think I will use etags after >> all. >> >> Thanks again! >> >> On Sat, Nov 19, 2011 at 2:07 AM, Kyaw Tun <[email protected]> wrote: >> >>> >>> Will etag help? >>> Kyaw >>> >>> On Nov 17, 10:38 pm, David Rodrigues <[email protected]> wrote: >>> > Hi. >>> > >>> > I'm writing a synchronization script that syncs users A, B, and C's >>> > contacts with user D's contacts (all in GMail/contacts -- no 3rd party >>> > contacts). I am attempting to accomplish this without having to retain >>> any >>> > information between syncs. >>> > >>> > When comparing contacts, my program decides what contact to update by >>> > checking the "updated" property from two similar entry objects (say, >>> "Joe >>> > Smith" from user A and "Joe Smith" from user D). It then can determine >>> > which contact was updated most recently and update the other >>> accordingly. >>> > The problem is that when appropriate contact gets updated, the next >>> sync >>> > will see a more recent "updated" property on that contact and then >>> sync in >>> > the other direction. Since this and subsequent syncs between these >>> contacts >>> > doesn't actually update anything (the contact's data is identical), >>> Google >>> > does not update the "updated" property on the associated contact. So >>> now >>> > every time the app runs, a wasted attempt at syncing two identical >>> contacts >>> > fires off. >>> > >>> > This method actually works, since nothing is changed on the false >>> syncs, >>> > but it is ugly and wastes network and computer resources (not to >>> mention >>> > time). Does anyone have an idea how I can work around this issue? Keep >>> in >>> > mind I don't want to save any data between syncs. I've tried using a >>> "jot" >>> > to mark the contacts being compared with identical "time stamps", then >>> I >>> > used this value in conjunction with the "updated" property to decide >>> if and >>> > which way to sync. The implementation has started getting (too) >>> complex and >>> > ugly, so I thought I'd ask here before continuing that path. >>> > >>> > Thanks for any help you can provide! >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Google Contacts, Shared Contacts and User Profiles APIs" 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://code.google.com/apis/contacts/community/forum.html >>> >> >> >> >> -- >> * >> * >> *PLEASE UPDATE YOUR RECORDS WITH MY NEW PHONE NUMBER:* >> *609-849-8499* >> >> David Rodrigues >> David Rodrigues Consulting >> 609-848-8299 >> http://www.davidrodriguesconsulting.com <http://www.davidrodrigues.com> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Google Contacts, Shared Contacts and User Profiles APIs" 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://code.google.com/apis/contacts/community/forum.html >> > > > > -- > Alain Vongsouvanh | Developer Programs Engineer > > -- > You received this message because you are subscribed to the Google > Groups "Google Contacts, Shared Contacts and User Profiles APIs" 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://code.google.com/apis/contacts/community/forum.html > -- * * *PLEASE UPDATE YOUR RECORDS WITH MY NEW PHONE NUMBER:* *609-849-8499* David Rodrigues David Rodrigues Consulting 609-848-8299 http://www.davidrodriguesconsulting.com <http://www.davidrodrigues.com> -- You received this message because you are subscribed to the Google Groups "Google Contacts, Shared Contacts and User Profiles APIs" 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://code.google.com/apis/contacts/community/forum.html
