[Bug 14540] Names interface - Aliasing replacement with separate nickname, local alias etc.

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=14540

--- Comment #36 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #35)
> 1) I would like to get this merged without any local cache, to not delay for
> another 10months. I guess this means that gabble will have to keep is hack
> (storing nickname in roster) for now.

It would make me sad to have an implementation in Gabble that still subverted
the "local-alias is user-chosen" rule, particularly since Wocky links sqlite
already... but I do see your point.

If we don't get this right first time, I would definitely like to have a clear
picture of how we're going to Do It Right™ later, so that we know the API
doesn't rule it out altogether.

I'm tempted to say "how hard can it be?" and try implementing it, tbh... all we
need is a sqlite database (contact => vCard) or (contact => vCard-derived
nickname) in ~/.cache?

(Slight complicating factor that the regression tests might need to clear it
out once per test or something.)

It's a pity that XMPP doesn't allow us to store metadata on our roster, other
than aliases and groups...

(In reply to comment #34)
> I would like to see an implementation of this specification for Gabble (a CM
> where nicknames are server-stored and local aliases exist) and either Salut
> or Rakia (a CM where they aren't, and they don't, respectively). The
> Salut/Rakia case is the easier one. Ideally, I'd also like to see a MC
> implementation (which shouldn't be too hard with my latest MC refactoring).

Do you have WiP branches for any of these or would you like me to hack on them?

> Who caches - telepathy-glib or the CM? I vaguely lean towards the CM because
> Gabble (or eventually Wocky) could cache entire vCards (or
> entire-vCard-except-PHOTO since avatars are separate?), not just the
> nickname, which would give us "cheap" cached ContactInfo too.

If you're pushing the "implementing it at all is better than not" angle, having
the CM declared to be responsible for persistence (if any) shortens the
shortest path from here to an implementation, I think.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.