[Bug 23156] replace handles with (namespace, identifier) tuples

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Connection, Channel: make   |replace handles with
                   |handles implicitly be       |(namespace, identifier)
                   |contact handles             |tuples
  Status Whiteboard|later                       |incompatible
         Depends on|                            |23148
             Blocks|23148                       |

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-12-01 02:55:10 PST ---
In <https://bugs.freedesktop.org/show_bug.cgi?id=23155#c8> Will wrote:
> Brainstorming this with Rob, Pekka and Aki at the MeeGo Conference led to the
> following rough proposal for 1.0:
> 
>   • In the D-Bus API, replace handles with (ss) tuples, where the first field
> is the vCard field, and the second field is the contact ID.
>   • Cellular conference call-style meaningless channel-specific-handles could
> have a dummy namespace and look something like this: ("meaningless",
> "1234:really:tel:+441234567890").
>   • General channel-specific handles could have some similar convention. Or
> maybe we could use (sss) throughout.
> 
> Using tuples rather than just strings makes Addressing more native than it
> will be in 0.x; it also makes it more obvious to applications that they
> should only store things that the CM has normalized. The argument that
> applications will confuse normalized and non-normalized strings is fair,
> but applications not using bindings mess up handles, too, and in
> applications using bindings we can use the host language's type system
> to distinguish the two.
>
> Using strings throughout would make dbus-monitor traffic easier to read,
> would remove a whole section of Telepathy that currently needs
> explaining, and would also remove the memory-leak objection to
> immortal handles: CMs could forget contact ID tuples when they're done
> with them, safe in the knowledge that they can re-create them if a
> client uses one.
>
> (Internally, telepathy-glib's API could replace TpHandle with GObjects
> that get passed around implementing a particular interface...
> TpSvcContact, say. This preserves fast comparisons and so on.)

I agree with this proposal, except that I'm not sure about making the namespace
portion be a vCard field. Normatively referencing vCard for ContactInfo is
fine, but I'm not sure that our entire addressing model should be vCard when
most of the protocols we deal with don't have an official vCard field.

Alternatives include: another externally-defined thing (URI scheme?), a string
chosen by the CM (with "" denoting the protocol's "native" namespace perhaps),
or the Telepathy name of the protocol (defined by tp-spec with scope for
CM-specific extensions).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.