Maemo 5 uses various extended interfaces beyond what's in telepathy-spec. One such interface is the GSM interface: http://git.collabora.co.uk/?p=rtcom-telepathy-glib.git;a=blob;f=rtcom-telepathy-glib/Connection_Interface_GSM.xml which includes an "IMSI" property. We should decide whether this is in-scope for Telepathy, and standardize it if it is.
I've pushed an initial spec to http://git.collabora.co.uk/?p=user/dilinger/telepathy-spec;a=shortlog;h=refs/heads/cellular It's pretty simple, just IMSI and IMSIChanged..
Putting at least the SMSC on this interface too seems sensible? The message validity period could conceivably apply to other protocols too, I suppose, but... (Are those overrideable on individual SMSes?)
(In reply to comment #2) > Putting at least the SMSC on this interface too seems sensible? Indeed, added MessageServiceCentre (renamed) from the original ring spec. > The message validity period could conceivably apply to other protocols too, I suppose, but... > > (Are those overrideable on individual SMSes?) IMHO the message validity period could be useful enough for other protocols too (IIRC there's supposed to be a XEP for this, too, but I can't find it ATM). Also, the message validity period is actually per-message, so IMHO it makes sense to put it in Channel.I.Messages. OTOH, I wouldn't go so far as to create Connection.I.Messages just to put the connection-default validity period there. So I propose that C.I.Cellular keeps MessageValidityPeriod property. Renamed SMS* to Message* since all of the properties could be applicable to other cellular services as well, and not neccessarily be called SMS there (though CDMA apparently calls SMS' SMS too). Also tried to be more precise for MessageValidityPeriod - define units used (so we're talking seconds, not eg. days), and outline possible limitations (rounding, maximum timeout). I wouldn't go so far as to explicitly define rounding and timeout, since we would be generalising on the basis of just one data point (GSM SMS). Updated branch is at: http://git.collabora.co.uk/?p=user/ptlo/tp-spec-senko/.git;a=shortlog;h=refs/heads/cellular
Looks fine. I guess we can define a 'message-validity' key for Messages as and when we need it.
review+ as a draft from me too. Some non-blocker comments: > + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> > + <p>This interface is for various cellular things (GSM and/or CDMA) things that > + aren't really applicable to other protocols.</p> > + </tp:docstring> remove the second instance of "things" > + <property name="MessageValidityPeriod" tp:name-for-bindings="Message_Validity_Period" > + type="u" access="readwrite"> This doesn't seem to have any change notification. Either add some, or explicitly say that there isn't any at the moment and UIs should retrieve it once for each time they want to display it (or something)? (In practice I think this'd manifest as: when you click on "Cellular" in a settings menu or something, a dialog opens, and that dialog retrieves the property exactly once) Also, in future I'd like a blank line between <p> elements to improve source readability (and usability of the {} keys in vim :-) > + <p>The International Mobile Subscriber Identifier, if it exists. This > + would originate from a SIM card. If the IMSI is unknown, this will > + contain an empty string ("").</p> Do we want to distinguish between "no SIM" and "I have a SIM but I don't know its IMSI"? If we do, we could represent "no SIM" as a reserved string that isn't syntactically a valid IMSI, perhaps "-"; but we probably don't actually care.
(In reply to comment #5) > remove the second instance of "things" Fixed in my trivia branch > Also, in future I'd like a blank line between <p> elements to improve source > readability (and usability of the {} keys in vim :-) Fixed in my trivia branch
Remaining issues before undrafting this: > > + <property name="MessageValidityPeriod" tp:name-for-bindings="Message_Validity_Period" > > + type="u" access="readwrite"> > > This doesn't seem to have any change notification. Either add some, or > explicitly say that there isn't any at the moment and UIs should retrieve it > once for each time they want to display it (or something)? This needs information from someone who understands cellular things. If the CM always knows this information, then change notification would be easy, and should be added. If the CM has to poll this (e.g. ask the SMSC), there needs to be some way to refresh it (a RequestMessageValidityPeriod method, perhaps), and the property should be re-documented to be the last known value. Get() on a property, as we currently implement them, can't wait for an async round-trip, and I think that's a good pattern to keep. > > + <p>The International Mobile Subscriber Identifier, if it exists. This > > + would originate from a SIM card. If the IMSI is unknown, this will > > + contain an empty string ("").</p> > > Do we want to distinguish between "no SIM" and "I have a SIM but I don't know > its IMSI"? If we do, we could represent "no SIM" as a reserved string that > isn't syntactically a valid IMSI, perhaps "-"; but we probably don't actually > care. This needs a decision from someone who understands cellular things and UI requirements (Lassi?) before undrafting. I don't care either way.
(In reply to comment #7) > > This doesn't seem to have any change notification. Either add some, or > > explicitly say that there isn't any at the moment and UIs should retrieve it > > once for each time they want to display it (or something)? > > This needs information from someone who understands cellular things. The validity period is set by the client and encoded in each SMS we submit. Clients typically store the setting in MC which handles the change notifications already. > > Do we want to distinguish between "no SIM" and "I have a SIM but I don't know > > its IMSI"? If we do, we could represent "no SIM" as a reserved string that > > isn't syntactically a valid IMSI, perhaps "-"; but we probably don't actually > > care. > > This needs a decision from someone who understands cellular things and UI > requirements (Lassi?) before undrafting. I don't care either way. I would say we don't need to distinguish between the two cases...
(In reply to comment #8) > (In reply to comment #7) > > > This doesn't seem to have any change notification. Either add some, or > > > explicitly say that there isn't any at the moment and UIs should retrieve it > > > once for each time they want to display it (or something)? > > > > This needs information from someone who understands cellular things. > > The validity period is set by the client and encoded in each SMS we submit. > Clients typically store the setting in MC which handles the change > notifications already. Ah, so this is just CM configuration, and doesn't really need its own change notification if clients are using the AccountManager correctly. Thanks, I'll prepare a spec branch that explains this. > > > Do we want to distinguish between "no SIM" and "I have a SIM but I don't know > > > its IMSI"? If we do, we could represent "no SIM" as a reserved string that > > > isn't syntactically a valid IMSI, perhaps "-"; but we probably don't actually > > > care. > > > > This needs a decision from someone who understands cellular things and UI > > requirements (Lassi?) before undrafting. I don't care either way. > > I would say we don't need to distinguish between the two cases... Fair enough.
Review of smcv/cellular would be appreciated. I've added wording that the message validity and the SMSC SHOULD be a DBus_Property parameter, and SHOULD be set via the AccountManager if possible. Does anything else block undrafting this? Presumably telepathy-ring already implements something equivalent, so it passes the "has an implementation" test?
Branch merged, thanks. Someone involved in implementing this can advise when it's ready to undraft.
Here is a spec branch adding a boolean property for using a reduced character set: http://git.collabora.co.uk/?p=user/wjt/telepathy-spec-wjt.git;a=commitdiff;h=cellular-reduced-charset And here is the HTML version of it: http://people.freedesktop.org/~wjt/telepathy-spec-cellular_reduced_charset/spec/Connection_Interface_Cellular.html#org.freedesktop.Telepathy.Connection.Interface.Cellular.DRAFT.MessageReducedCharacterSet The interface could be undrafted without this, but since this is a reasonably simple property to add...
I approve of this branch, and I don't see anything that prevents undrafting it.
aaaaand merged! http://git.collabora.co.uk/?p=telepathy-spec.git;a=commitdiff;h=b0316708c618cbcaf2c0061430cc376bb6d0ca77 Will be in telepathy-spec 0.19.8, including MessageReducedCharacterSet.
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.