Hi, > -----Original Message----- > From: telepathy- > [email protected] > [mailto:telepathy- > [email protected]] 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 [email protected]” than “well, you have to ask the account > manager for all accounts, and then look at all the contact lists and > find [email protected] 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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
