[Bug 28866] New: Allow channel requesters to associate metadata with requests for the benefit of other clients

[bugzilla-daemon at freedesktop.org]

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

           Summary: Allow channel requesters to associate metadata with
                    requests for the benefit of other clients
           Product: Telepathy
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: tp-spec
        AssignedTo: telepathy-bugs at lists.freedesktop.org
        ReportedBy: will.thompson at collabora.co.uk
         QAContact: telepathy-bugs at lists.freedesktop.org


Currently, there's no way to relay additional information between a channel
requester and the ultimate observers and handlers of the resulting channel. The
main use case for which this poses a problem is associating contact IDs (in
particular, phone numbers) with particular contacts in your address book. When
I tell my N900 to call my mum, how does the call UI know that I'm trying to
call her and not my dad (who has the same phone number¹)? The current answer is
that it can't.

So I have written a spec branch which adds:

• A new immutable property, ChannelRequest.RequestMetadata: a{sv}, defined to
contain arbitrary metadata, which clients MAY choose to interpret but MUST cope
with the absence of [a];
• New methods on ChannelDispatcher to specify said metadata when making a
channel request [b];
• A new key in ObserveChannels' Observer_Info dict containing immutable channel
properties [c].

Handlers can already sign up to receive the immutable properties of channel
requests by implementing Client.Interface.Requests.

So this allows the call UI to know who you're calling, as well as any observers
(perhaps a call logger?), assuming the various components know the format by
which the platform-specific contact ID is included in the RequestMetadata. They
have to be able to deal with it being missing — a third-party app might not
specify this — but it allows this information to be passed if needed.

This could also be used to allow one process to request an outgoing file
transfer channel to be handled by another process, passing along the full path
to the file to be sent, which would allow nautilus-send-to's Telepathy plugin
to delegate the actual file transferring to Empathy, or vice-versa. Obviously
this involves slightly more active collusion — you have to know that the
handler will understand this key — but that's probably okay, we can specify
that and maybe have some mechanism to discover it.

[a]
http://people.freedesktop.org/~wjt/telepathy-spec-channel_request_metadata/spec/Channel_Request.html#org.freedesktop.Telepathy.ChannelRequest.RequestMetadata
[b]
http://people.freedesktop.org/~wjt/telepathy-spec-channel_request_metadata/spec/Channel_Dispatcher.html
[c]
http://people.freedesktop.org/~wjt/telepathy-spec-channel_request_metadata/spec/Client_Observer.html#org.freedesktop.Telepathy.Client.Observer.ObserveChannels

1. actually in my case they don't, but the point stands. ☺

-- 
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.