Maemo 5 uses various extended interfaces beyond what's in telepathy-spec. One such interface is an API for reliable store-and-forward protocols, like SMS: http://git.collabora.co.uk/?p=rtcom-telepathy-glib.git;a=blob;f=rtcom-telepathy-glib/Connection_Interface_StoredMessages.xml We should incorporate this functionality into the main telepathy-spec.
Initial spec committed to http://git.collabora.co.uk/?p=user/dilinger/telepathy-spec;a=shortlog;h=refs/heads/msgstore I left out the "stored-message-received" and "rescued" keys, as that appears to be unused by the API, and should possibly be CM-specific. Other than that (and various renames), it's functionally pretty similar to rtcom's StoredMessages iface.
> + storage capabilities for incoming messages. An example of > + a protocol that might use this is email; the CM could keep E-mail is outside the scope of Telepathy; SMS would be a better example. > + <p>The well-known key "message-token" (as defined in > + <tp:type namespace="org.freedesktop.Telepathy.Channel.Interface.Messages">Message_Part</tp:type>) > + MUST be included in the message header for storage to be supported.</p> That's a shame, because that would exclude SMS. :-P (Saying that messages MUST either have message-token or the recently introduced protocol-token would be OK, though. See <http://git.collabora.co.uk/?p=telepathy-spec.git;a=commitdiff;h=5252993ac86e5c9fe9872db47d68980873d18690>) > + <!-- XXX: document stored-message-received/rescued, or leave that up > + to the CM? --> rescued is part of Messages already, with semantics that aren't closely related to this interface. Do you intend this API to be the solution to Bug #23844 too, or is that orthogonal?
(In reply to comment #2) > > Do you intend this API to be the solution to Bug #23844 too, or is that > orthogonal? > Hm, I wasn't aware of that bug 'til now. Perhaps it should include support for XMPP logging as well? After a quick skim over the spec, it looks like we'd just need to add: - property EnableArchiving (r/w), of type enum { Auto, Manual, Disabled }. This should probably have a channel iface as well. Also, perhaps a related signal (ArchivingModeChanged)? - discussion of retrieving collections, similar to RedeliverMessages, but allowing selection by start/end address ranges. Either w/ separate API functions (like RedeliverMessageRange()), or by allowing a more flexible indexing method (not just message-token, but also thread-id, as well as start/end/with/page). - DeleteMessages may return NotImplemented and/or PermissionDenied (the former for CMs that only support archiving, the latter for servers that force archiving for security reasons).
There are protocols such as SIP, or XMPP with the SM extension, which do not have semantics of service-side storage, but they could benefit from reliable acking. The acknowledgements of Channel.Type.Text are understood to signal when the message is shown, so they cannot be used for protocol acking which imposes time limits on message transactions. Can there be a small interface just for this purpose? StoredMessages could be built up on top for protocols that add service-side storage.
Relatedly, we should probably have API to rescind an unsent outgoing message. If you're on the London Underground (which to London's lasting shame has no GSM coverage), you might send a text, realise you'd sent it to the wrong person, and want to cancel sending it. Perhaps it's worth generalizing this interface to encompass that as well.
*** This bug has been marked as a duplicate of bug 28742 ***
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.