[codebaobab]

Anil, why didn't you just ignore fields and attributes that were missing? So if education:concentration returns "CompSci" on the first call, but then is missing on the second call, don't treat that as a change. Don't consider the attribute changed until the it is present and different.

[anilchawla]

Right, I also thought I could work around the issues by ignoring fluctuations in the data. The problem is knowing what is the correct baseline data. In your example, the education:concentration might be missing when you first start checking and only start appearing a long time later. Do you ignore the data when it first appears or report that the person just added another major at college (which may be true!)? This is a bigger problem with fields that people might completely add/remove instead of simply updating (e.g. relationship status). I tried baking in a time period (e.g. 24 hours) in which I ignored all changes and waited for the baseline data to become obvious, but even that didn't work because some data took even longer to re-appear. At some point I had to admit to myself that - with all these work-arounds - my simple feature had turned into a hack.

[codebaobab]

I understand that having to work around fluctuating data might produce less than desirable results. But your users might find the feature useful anyway.

[anilchawla]

Thanks. I'm definitely keeping the code around since it's fully implemented. I might either reduce the scope of the alerts (for example, ignore add/remove and focus on changes only) or just bring it back when I have more confidence in the API.

[soulclap]

So what if it is missing on the first call? How many calls until you get the complete picture? And which of those results is 'the truth' and reflects the current status?

[baffledshrimp]

Also, some things like relationship status might go from 'dating' to blank after a breakup if the person doesn't want to scream that they're single right away