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 f...@bar.com” than “well, you have to ask the account
manager for all accounts, and then look at all the contact lists and
find f...@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
_______________________________________________
telepathy mailing list
telepathy@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/telepathy
