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.
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?).
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)
I prefer MAY, because it makes it slightly easier for channel implementors (you can just make it a fixed interface). Updated with your feedback.
This looks OK to me.
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.