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

[mikhail.zabaluev at nokia.com]

Hi,

> -----Original Message-----
> From: telepathy-
> bounces+mikhail.zabaluev=nokia.com at lists.freedesktop.org
> [mailto:telepathy-
> bounces+mikhail.zabaluev=nokia.com at lists.freedesktop.org] On Behalf Of
> ext Will Thompson
> Sent: Thursday, March 03, 2011 4:40 PM
> To: Olli Salli
> Cc: Telepathy
> Subject: Re: [Telepathy] On spec additions to allow a really simple IM
> API
> 
> 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.

I too think send-only channels are an ugly solution and will only complicate everything.
Remember that the case is meant mainly for simple applications sending one-shot messages, so involving special channels in this flow looks like overkill. Especially as they need to be secretly associated with proper chat channels.
A CD extension looks like lesser evil to me. That, or maybe try client-side helpers to manage sending to a contact survivably across channel closures.

Best regards,
  Mikhail