GNOME Bugzilla – Bug 629311
Folks should normalize IDs written to the writable backend
Last modified: 2010-09-18 21:07:43 UTC
This will probably be tricky to get exactly right, but it would be nice to replace IDs used in the writable backend with their normalized equivalent. For instance, the AIM contact ID "Foo Bar Baz " should be normalized as "foobarbaz", since neither whitespace nor case are significant in AIM. Of course, we don't want to hard-code this in our own code. For Telepathy-sourced contact IDs, we should normalize with Protocol.Normalise (if available) or InspectHandle(RequestHandle(...)). As it stands, if writable backend contains an un-normalized contact ID, they won't be properly associated with the corresponding TpContact (whose ID will always be normalized).
The folks-import tool potentially exposes this bug for AIM accounts imported from Pidgin. A work-around is to manually normalize AIM account names in ~/.local/share/folks/relationships.ini (make the contact IDs all lower-case and remove whitespace). (The same issue is theoretically true for any other type of account where the contact ID wasn't normalized in the blist.xml file before importing, but I'm not aware any other protocols where this might be common).
I think this might have to be a method on the IMable interface, actually, since that's the only code in libfolks which explicitly deals with IM identifiers. Since that's in the core of libfolks, we're either going to end up adding a tp-glib dependency to the core of folks, or copying its normalisation code.
Created attachment 170129 [details] [review] Normalise IM addresses before adding them to IMable.im_addresses http://git.collabora.co.uk/?p=user/pwith/folks;a=shortlog;h=refs/heads/629311-normalise-im-addresses This takes the approach of adding an IMable.normalise_im_address() method, which has its own normalisation code for all the protocols I could find which require it. It's not too much code, and I don't think we can justify adding a tp-glib dependency to the core of libfolks just for this.
Pushed to folks-0-1: commit bd57e3a68bfc19138300379888b56d03edaf362c Author: Philip Withnall <philip.withnall@collabora.co.uk> Date: Mon Sep 13 11:16:29 2010 +0100 Bug 629311 — Folks should normalize IDs written to the writable backend Add a new IMable.normalise_im_address() method, which should be called on any IM address added to IMable.im_addresses, normalising it so that only the canonical version is used within libfolks. Closes: bgo#629311 backends/key-file/kf-persona.vala | 31 +++++++++--- backends/telepathy/lib/tpf-persona.vala | 3 +- folks/imable.vala | 79 +++++++++++++++++++++++++++++++ 3 files changed, 105 insertions(+), 8 deletions(-)
Pushed to master: commit 0489968d1a76ccd296b8b60ce9862d822b3863ec Author: Philip Withnall <philip.withnall@collabora.co.uk> Date: Mon Sep 13 11:16:29 2010 +0100 Bug 629311 — Folks should normalize IDs written to the writable backend Add a new IMable.normalise_im_address() method, which should be called on any IM address added to IMable.im_addresses, normalising it so that only the canonical version is used within libfolks. Closes: bgo#629311 backends/key-file/kf-persona.vala | 31 +++++++++--- backends/telepathy/lib/tpf-persona.vala | 3 +- folks/imable.vala | 79 +++++++++++++++++++++++++++++++ 3 files changed, 105 insertions(+), 8 deletions(-)
(In reply to comment #3) > Created an attachment (id=170129) [details] [review] > Normalise IM addresses before adding them to IMable.im_addresses > > http://git.collabora.co.uk/?p=user/pwith/folks;a=shortlog;h=refs/heads/629311-normalise-im-addresses > > This takes the approach of adding an IMable.normalise_im_address() method, > which has its own normalisation code for all the protocols I could find which > require it. > > It's not too much code, and I don't think we can justify adding a tp-glib > dependency to the core of libfolks just for this. Ex post facto review: This approach generally looks good. Obviously, it'd be nicer to rely only upon the normalization from the server, but like you said, we don't want to strictly depend upon tp-glib in the core for this. And the rules for normalization shouldn't change for each protocol, which narrows down our range of bugs to our specific implementation. Definitely worth merging anyhow.