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

[Will Thompson]

Hello,

I would like us to be able to implement this convenience API:

   class SimpleTextThingy {
     public:
       SimpleTextThingy(Tp::Contact &contact);

       /* Send a message to contact, optionally spawning/presenting the
        * UI for the channel. */
       void sendMessage(Tp::Message &message, bool presentUI);

       /* Present a conversation window to contact, with a message ready
        * to send. Think "share link with...": you want to give the user
        * the chance to edit the message before sending it. */
       void presentMessageForSending(Tp::Message &message);

     public signals:
       void messageSent(Tp::Message &message);
       void messageReceived(Tp::Message &message);
   }

The signals are easy: just be an observer for Text channels to contact. 
  The methods are harder. Simon and I talked about them today.

If we add a variation of the ChannelRequest.Succeeded signal which also 
gives you the channel path, this lets us implement sendMessage("foo", 
true), namely popping up the conversation window to that contact (by 
calling EnsureChannel() and letting the default handler get it) and then 
poking a message into the channel. Of course there's a race here: if the 
handler Close()s the channel before you call SendMessage(), you lose. 
Hack: the library could just try again, but that would probably piss the 
user off. This will happen only rarely in practice, but it would still 
be unpleasant.

sendMessage("foo", false); - that is, without presenting the normal UI 
whether or not it's already open — is more problematic. If you use 
ChannelDispatcher.CreateChannel() with yourself as the preferred 
handler, it fails if the user has a conversation window open to that 
contact. If you use CD.EnsureChannel(), it refocuses the conversation 
window if there is one. Options, none of which I like:

• We could add Connection.SendAMessage(). This is ugly, and would break 
loggers logging outgoing messages. Vetoed.
• We could add send-only text channels, which you can always Create 
regardless of whether there's another channel going on. No incoming 
messages are reported by them; you can just call SendMessage(). 
MessageSent fires on the send-only channel, as probably do delivery 
reports for the messages you send on that channel. Incoming messages 
don't show up.
• We could allow more than one fully-functional text channel to a 
contact, with MessageSent and MessageReceived firing on all of them. 
This involves loggers de-duplicating messages, but they kind of have to 
do that anyway.
• Your really clever option here?

presentMessageForSending is actually the easiest of the bunch: if we 
allow associating hints with channel requests — 
https://bugs.freedesktop.org/show_bug.cgi?id=28866 — then we can just 
define a key which means "oi, present this message for sending".

Thoughts very welcome,
-- 
Will