GNOME Bugzilla – Bug 117554
Make it visible that we are waiting for a vCard in the add-contact dialog
Last modified: 2005-04-22 20:57:06 UTC
Now you don't know whether you are waiting for a vCard reply or if you got an empty one back.
Created attachment 22430 [details] [review] Fixes this bug.
Hmm .. wonder what I was thinking when doing the issue reporting. It already does this. I probably meant the Contact Information dialog which says "Information not available" all the time. Changing the summary to reflect this. We should probably have a timeout on the waiting for the vcard.
:) I thought as much - I wasn't sure what exactly you mean't either, ill add to this patch.
What's the deal? I'm slightly confused by you two crackpots! ;) Is the patch commited? Should it be commited?
Richard, it neither is commited or should be :) I had mixed up the description of the issue so the patch "fixed" an already working part :)
Ok, so the latest on this bug: 1. Make the add-contact druid display a "Retieving information"-label 2. Have a timeout (30 sec) and cancel after that. 30 sec shouldn't make a slow network affect things and we would handle clients that just don't reply. 3. Fill out the values when we get the answer (like we do now), possibly with a "Not available" label if we get empty strings.
Created attachment 45527 [details] [review] Does as Richard describes One or two things to note. 1. Some people have vcards where the subnode is called "vcard" not "vCard", as a result this means the information is not picked up. Need to clarify the standard on this! 2. Should this patch use the <NICKNAME> field for the nickname that is used to populate the entry box? Currently it is guessed from the JID.
Added PATCH keyword.
Martyn, wouldn't it be possible to accept both vcard and vCard (and other case combinations), but make sure to only generate vCard, as the standard would say?
I guess it could be done. I say "some people", I have noticed one or two and they are usually done that way because of buggy clients. Currently the loudmouth doesn't use strcasecmp, which would mean a bit of messing about to find the string and manually calling strcasecmp. This is just one instance of many XML elements which could have the same problem. If we allow case insensitive elements here, we really should everywhere else.
Hmm .. couldn't you just call: strcasecmp (lm_message_node_get_value (node), "vcard")? I haven't looked at the code right now so I might misremember how it's done.
I think the API used in this case is: lm_message_node_get_child (node, "vCard") I guess it could be done by getting each child in a for loop and strcasecmp'ing them node names but if the "vCard" node is incorrect, the likelyhood is that the same problems will exist with nodes like the FN, NICKNAME, etc (which are in uppercase). It would be a much better idea IMO to have a loudmouth API for this.
Yeah, though I seem to recall that using anything other than vCard is not being standard compliant. I don't really want to clutter the Loudmouth API with functions to handle broken XML.
Commiting this one to CVS for now, closing this but, we can discuss the issue of broken clients (or relookup if they are broken :) in another thread.