# HG changeset patch # User Paul Aurich # Date 1241376671 0 # Node ID afc3ec89e83bf2dec3014895bc3504cff15ef295 # Parent 50edd9c80577ef6dba42d08ce5b32a2445c02678 Revert the partial hack for ejabberd 2.0.0. See comment in code. diff -r 50edd9c80577 -r afc3ec89e83b libpurple/protocols/jabber/useravatar.c --- a/libpurple/protocols/jabber/useravatar.c Sun May 03 18:50:20 2009 +0000 +++ b/libpurple/protocols/jabber/useravatar.c Sun May 03 18:51:11 2009 +0000 @@ -45,6 +45,9 @@ static void remove_avatar_0_12_nodes(JabberStream *js) { +#if 0 + See note below for why this is #if 0'd + /* Publish an empty avatar according to the XEP-0084 v0.12 semantics */ xmlnode *publish, *item, *metadata; /* publish the metadata */ @@ -61,16 +64,26 @@ /* publish */ jabber_pep_publish(js, publish); +#endif /* - * This causes ejabberd 2.0.0 to RST our connection unceremoniously, - * so disable it for now (we publish a to the metadata node - * instead. + * This causes ejabberd 2.0.0 to kill the connection unceremoniously. + * See https://support.process-one.net/browse/EJAB-623. When adiumx.com + * was upgraded, the issue went away. + * + * I think it makes a lot of sense to not have an avatar at the old + * node instead of having something interpreted as "no avatar". When + * a contact with an older client logs in, in the latter situation, + * there's a race between interpreting the vcard-temp:x:update + * avatar (non-empty) and the XEP-0084 v0.12 avatar (empty, so show no + * avatar for the buddy) which leads to unhappy and confused users. + * + * A deluge of frustrating "Read error" bug reports may change my mind + * about this. + * --darkrain42 */ -#if 0 jabber_pep_delete_node(js, NS_AVATAR_0_12_METADATA); jabber_pep_delete_node(js, NS_AVATAR_0_12_DATA); -#endif } void jabber_avatar_set(JabberStream *js, PurpleStoredImage *img)