[Telepathy] On spec additions to allow a really simple IM API

[Will Thompson]

Hello,

On 02/03/11 20:33, Olli Salli wrote:
> In essence, CD would implement a method, say
> CD.I.Messages.Send(s:TargetID, s:message, <and perhaps some misc args
> for flags, and maybe throw an a{sv} there just for the kicks>), in the
> following way:
> 
> - EnsureChannel a suitable text channel for sending the message to the recipient
> - Send the message on the resulting Channel
> - If sending failed, which in particular can happen at least when
> Yours wasn't true and somebody else Closed it when we tried to send,
> just request the channel again, and try sending again

So when considering similar solutions in the past (but not inside MC:
that's a new idea!) I was worried about going into a loop. I'm not 100%
sure that the above is loop-free in the presence of someone else
requesting the channel at the wrong time, and/or a broken observer that
closes all your channels. (But in the latter case everyone dies anyway.)

> This depends on a few things:
> - If it is safe to implement CreateChannel in the CD as Ensure + not
> Closing - the CD knows that it's the only other user of the Ensured
> channel (unless somebody else is directly poking the Connection, but
> that's broken anyway), so it could be the only one Closing it, but it
> can avoid that because it knows of the new request

Technically this is wrong if it's possible to have >1 separate
conversations with a contact on a particular protocol (say, using XMPP
threads). MC would have to try to guess whether a 1-1 text channel
request was “standard” or not, or something.

For instance, check out
http://telepathy.freedesktop.org/spec/Channel_Interface_SMS.html — the
SMSChannel property allows you to ask for messages to be sent via SMS
rather than over the internet on protocols which support both.

This is the biggest worry I have with this solution to the problem:
right now, MC is completely agnostic of the contents of requests. It
just does a{sv} pattern-matching and knows no semantic details. Baking
in special knowledge of text channels makes it harder to do clever stuff
in future without adding special-cases to MC.

> - If it is safe to Close the channel when we're done if nobody
> requested it in the meantime: It should be, as if we use Close instead
> of Destroy, if there were incoming messages the Channel should then be
> closed and redispatched, right?

This should be safe.

> - If it is problematic that the Channel might be redispatched after
> Closing with its pending message queue intact, namely for loggers not
> wanting duplicate events? We haven't given the Channel to a Handler
> which could ack the messages beforehand, that is.

This is the same as a handler closing a channel while it has pending
messages, and it respawning. The messages get marked as 'recovered' to
make it easier for observers.

> Also, do you think this would complicate the CD implementation too
> much (or be in fact impossible)?

This bit of the channel dispatcher is quite complicated already. I'm a
bit scared of baking more magic into it… I believe it's *possible*, but
may lead to hard-to-catch bugs.

> I'm fine with send-only Channels -
> they'd solve the issue equally well, and without any CD changes, but
> would in turn require changes in ALL of the CMs, and non-trivial
> tp-glib support, which looks problematic at this point to say the
> least. Not to mention the fact that "send-only" channels are an
> awkward concept at best.

I have conceptual issues with send-only channels too: they're a total
hack! It's also much harder to explain to a new-comer. There's a certain
conceptual simplicity to having an actual JustSendAMessageToAContact()
D-Bus method that people can use without having a full Telepathy library
to depend on. “dbus-send blah blah blah” is a much nicer answer to “how
do I send a IM to foo at bar.com” than “well, you have to ask the account
manager for all accounts, and then look at all the contact lists and
find foo at bar.com and then be a handler and then request-and-handle a
write-only text channel and then you can actually send the message”…

But if we took the write-only channels route, we could put the
SendAMessage(s: contact_identifier, s: message) magic method on (say)
the logger in the future. One doesn't preclude the other.

I'd be interested to hear from CM hackers what they think about this.
-- 
Will