pidgin: e9fdd89a: jabber: Strip the '/' off of a JID in ja..
paul at darkrain42.org
Wed Aug 26 23:05:00 EDT 2009
And Mark Doliner spoke on 08/26/2009 05:54 PM, saying:
> On Wed, Aug 26, 2009 at 5:42 PM, Paul Aurich<paul at darkrain42.org> wrote:
>> And Mark Doliner spoke on 08/22/2009 04:51 PM, saying:
>>> Hmm, is this change ONLY needed to handle the case where our JID ends
>>> in a slash? I wonder if there is another way we could fix this...
>>> like maybe not appending the slash? Or appending a default resource?
>>> Or changing jabber_id_new() to ignore a trailing slash? I'm afraid
>>> that Jabber's normalize function gets called often and the extra
>>> strlen and strdup could be expensive.
>> How does the attached patch look? I'm not sure if other prpls use (and
>> expect) the last separator to be appended even when the last field is
>> empty, so . This version should be less memory-happy.
oops, forgot to finish the thought. That should be "so I wasn't sure how
well that would work." I looked through all the ones distributed with
libpurple and the only one that seems to use an account split with the
last entry's default value "" is SIMPLE, but it fails properly if
there's no "@" in the username.
> That looks ok to me. If a JID ends in a slash shouldn't it be
> considered invalid and jabber_normalize() should return NULL? I guess
> it might not matter within the jabber prpl.
jabber_normalize itself is used only a handful of times in the prpl
itself, all in situations where I don't think it will be a problem (and
it could probably be replaced with jabber_id_new).
Also, having jabber_normalize deal with the '/' might be better than
returning NULL, because it means that we can be a little more lax in
dealing with user input for adding buddies and other things (and
libpurple falls back to using g_utf8_normalize, which isn't always
correct. side note: shouldn't there be a way for the prpl to signal that
a UID is invalid?)
Perhaps we could do both this and the account split (patch for pidgin
attached, presumably finch is just a xerox copy)?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 1213 bytes
Desc: not available
More information about the Devel