Bug 31964

Summary:	Need way to request SMS channel
Product:	Telepathy	Reporter:	Danielle Madeley <danielle>
Component:	tp-spec	Assignee:	Danielle Madeley <danielle>
Status:	RESOLVED FIXED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	Keywords:	patch
Version:	git master
Hardware:	Other
OS:	All
URL:	http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/sms
Whiteboard:	review+
i915 platform:		i915 features:

Description Danielle Madeley 2010-11-28 18:48:34 UTC

Some protocols allow an SMS to be sent to a contact, without you knowing the contact's phone number. We need a way to request such text channels.

I am proposing adding a new, requestable property to Chan.I.SMS, which would indicate that a given text channel is for sending SMSes.

Clients that request this property MUST be given a channel that will send SMSes. Clients that do not include this property in the request MAY be given a channel that will send SMSes (e.g. Yafono).

It's possible with some protocols that this property could change during the lifetime of the channel (e.g. MSN, where IMs can be diverted to phone). So I suppose it should support change notification for those protocols.

Comment 1 Danielle Madeley 2010-11-28 19:27:41 UTC

API sketch:

http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/sms

http://people.freedesktop.org/~danni/telepathy-spec-sms/spec/Channel_Interface_SMS.html

I have also wondered about a different approach using a "Transport" property with associated enum: Unknown, Network, SMS; which then allows for future expansion (to what?).

Comment 2 Simon McVittie 2010-12-01 04:00:53 UTC

The property should perhaps be tp:immutable="sometimes" - on some protocols it'll be immutable. You could add tp:immutable="yes" to Flash while you're there.

I think having a boolean rather than a tristate enum is reasonable.

One concern I have about this branch is that it changes the semantics of a channel that implements Chan.I.SMS from "this channel carries SMSs" to "this channel might conceivably carry SMSs". I think that's probably OK, but it should be specifically stated in the intro docstring: something like this?

    The presence of this interface on a channel does not imply that
    messages will be delivered via SMS.

    This interface SHOULD NOT appear in the _Interfaces_ property of
    channels where SMSChannel would be immutable and false. It SHOULD
    appear on channels where SMSChannel is immutable and true, and
    also on channels where SMSChannel is mutable (i.e. channels that
    might fall back to sending SMS at any time, such as on MSN).

(or the first SHOULD NOT could be a MAY, if you'd prefer those semantics)

Comment 3 Danielle Madeley 2010-12-01 16:21:25 UTC

I prefer MAY, because it makes it slightly easier for channel implementors (you can just make it a fixed interface).

Updated with your feedback.

Comment 4 Simon McVittie 2010-12-09 09:59:26 UTC

This looks OK to me.

Comment 5 Danielle Madeley 2010-12-09 16:19:07 UTC

Merged.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.