Hi, I just noticed that something funny is going on with the IM ID data of my contacts - namely, yahoo messenger IDs (but not Skype ones) are all appearing twice in CardDavMate. The origin of this can be traced back to CardDav-Sync from my Galaxy S2: it sends every IM ID not in one but two different "encodings", like so:
X-YAHOO:this_id IMPP;X-SERVICE-TYPE=yahoo:ymsgr:this_id X-SKYPE:that_id IMPP;X-SERVICE-TYPE=skype:skype:that_id
While it certainly can be argued that this is not exactly good practice (RFC4770 that defines the IMPP syntax says nothing about allowing or prohibiting the alternative notation in parallel - strictly speaking CardDavMate being entitled to interpret this as FOUR individual IDs), I think we can safely say it's reasonable to merge any number of instances of the same specific protocol AND same exact ID to a single one when presenting it to the user (reducing the above to only two IDs). Especially since this is already happening with Skype - but not with Yahoo. Could this be implemented as proposed?
Regards, Attila
Hi Atilla,
there is already a code that merges multiple IM accounts into one. Please send my some example vcard files and I will check why these are not merged for you.
JM
On Mar 5, 2013, at 9:34 PM, Attila Asztalos attila.asztalos@gmail.com wrote:
Hi, I just noticed that something funny is going on with the IM ID data of my contacts - namely, yahoo messenger IDs (but not Skype ones) are all appearing twice in CardDavMate. The origin of this can be traced back to CardDav-Sync from my Galaxy S2: it sends every IM ID not in one but two different "encodings", like so:
X-YAHOO:this_id IMPP;X-SERVICE-TYPE=yahoo:ymsgr:this_id X-SKYPE:that_id IMPP;X-SERVICE-TYPE=skype:skype:that_id
While it certainly can be argued that this is not exactly good practice (RFC4770 that defines the IMPP syntax says nothing about allowing or prohibiting the alternative notation in parallel - strictly speaking CardDavMate being entitled to interpret this as FOUR individual IDs), I think we can safely say it's reasonable to merge any number of instances of the same specific protocol AND same exact ID to a single one when presenting it to the user (reducing the above to only two IDs). Especially since this is already happening with Skype - but not with Yahoo. Could this be implemented as proposed?
Regards, Attila
Hi Ján,
On Wed, Mar 6, 2013 at 12:30 AM, Ján Máté jan.mate@inf-it.com wrote:
Hi Atilla,
there is already a code that merges multiple IM accounts into one. Please send my some example vcard files and I will check why these are not merged for you.
I thought that's what I just did:
On Mar 5, 2013, at 9:34 PM, Attila Asztalos attila.asztalos@gmail.com
wrote:
Hi, I just noticed that something funny is going on with the IM ID data of
my contacts - namely, yahoo messenger IDs (but not Skype ones) are all appearing twice in CardDavMate. The origin of this can be traced back to CardDav-Sync from my Galaxy S2: it sends every IM ID not in one but two different "encodings", like so:
X-YAHOO:this_id IMPP;X-SERVICE-TYPE=yahoo:ymsgr:this_id X-SKYPE:that_id IMPP;X-SERVICE-TYPE=skype:skype:that_id
After a non-trivial amount of trying to find my way through CardDavMate, a quick test call of normalizeVcard() in data_process.js using the data above resulted in:
IMPP;X-SERVICE-TYPE=Yahoo:this_id IMPP;X-SERVICE-TYPE=skype:that_id IMPP;X-SERVICE-TYPE=yahoo:this_id X-SKYPE:that_id
...and immediately revealed that a) the Skype ID is not duplicated similarly to the Yahoo one only by virtue of not being supported at all - I'd call that a bug in itself, seeing as how "X-SKYPE" doesn't seem any less legit of a tag than "X-YAHOO" - and wikipedia [1] seems to agree. b) the unique() call probably misses to catch the double tag because of a single letter's case - the "Y" in "yahoo" tag that normalizeVcard() itself introduced (on line 2945) to replace the original "X-YAHOO".
Best regards, - Attila
-
Attila Asztalos -
Ján Máté