Re: [Telepathy] On spec additions to allow a really simple IM API
Hi,
-Original Message-
From: telepathy-
bounces+mikhail.zabaluev=nokia@lists.freedesktop.org
[mailto:telepathy-
bounces+mikhail.zabaluev=nokia@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 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.
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.
Re: [Telepathy] On spec additions to allow a really simple IM API
On 07/03/11 12:58, mikhail.zabal...@nokia.com wrote: That, or maybe try client-side helpers to manage sending to a contact survivably across channel closures. I'm pretty sure it's not possible to do this without the possibility of an infinite loop, or the possibility of breaking the UI. If there's no existing channel open to a contact, this API would have to create and handle the channel to avoid popping up an IM window in the user's face. But this means that, if the user happens to try to start a conversation at the same time, that channel request will fail (if using CreateChannel) or be redispatched to the service sending a one-shot IM (EnsureChannel). This is obviously very unlikely, but sod's law … -- Will ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] On spec additions to allow a really simple IM API
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Will Thompson Sent: Monday, March 07, 2011 3:10 PM To: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] On spec additions to allow a really simple IM API On 07/03/11 12:58, mikhail.zabal...@nokia.com wrote: That, or maybe try client-side helpers to manage sending to a contact survivably across channel closures. I'm pretty sure it's not possible to do this without the possibility of an infinite loop, or the possibility of breaking the UI. If there's no existing channel open to a contact, this API would have to create and handle the channel to avoid popping up an IM window in the user's face. But this means that, if the user happens to try to start a conversation at the same time, that channel request will fail (if using CreateChannel) or be redispatched to the service sending a one-shot IM (EnsureChannel). This is obviously very unlikely, but sod's law … You are right. Anyone for o.fd.Tp.Conn.I.MessageSender, with suitable hacks to avoid invoking approvers/handlers for a possibly created channel? Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] Announce: telepathy-mission-control 5.7.5
The “GRINNING CAT FACE WITH SMILING EYES” release. tarball: http://telepathy.freedesktop.org/releases/telepathy-mission-control/telepathy-mission-control-5.7.6.tar.gz signature: http://telepathy.freedesktop.org/releases/telepathy-mission-control/telepathy-mission-control-5.7.6.tar.gz.asc Enhancements: • Support the Observer.DelayApprovers property. Regards, G. ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
Re: [Telepathy] On spec additions to allow a really simple IM API
Hi, -Original Message- From: telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org [mailto:telepathy- bounces+mikhail.zabaluev=nokia@lists.freedesktop.org] On Behalf Of ext Will Thompson Sent: Monday, March 07, 2011 4:49 PM To: Zabaluev Mikhail (Nokia-MS/Helsinki) Cc: telepathy@lists.freedesktop.org Subject: Re: [Telepathy] On spec additions to allow a really simple IM API On 07/03/11 14:45, mikhail.zabal...@nokia.com wrote: Anyone for o.fd.Tp.Conn.I.MessageSender, with suitable hacks to avoid invoking approvers/handlers for a possibly created channel? The main reason I wanted to use channels for this, rather than a connection interface, is that otherwise observers will not notice the messages being sent. A connection interface is simpler but we have to figure out how these messages should get logged etc. Yes, so there should be a way to get the created channel to be observed, but not offered to approvers and/or handlers? May just setting Channel.Requested to true be enough? Best regards, Mikhail ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
[Telepathy] ANNOUNCE: telepathy-qt4 0.5.9
The planned engineering works for the last year release. telepathy-qt4 is a Qt 4 C++ binding for the Telepathy real-time communication framework, which can be used to implement user interfaces, loggers and other Telepathy components. Tarball: http://telepathy.freedesktop.org/releases/telepathy-qt4/telepathy-qt4-0.5.9.tar.gz Signature: http://telepathy.freedesktop.org/releases/telepathy-qt4/telepathy-qt4-0.5.9.tar.gz.asc The latest reviewed code is always available from: git://anongit.freedesktop.org/telepathy/telepathy-qt4 http://cgit.freedesktop.org/telepathy/telepathy-qt4/ (cgit) Enhancements: * fd.o#28367 - Added High-level API for StreamTube channels. * fd.o#34228 - Added API on Account for requesting Channels and handling them yourself, implemented properly using the Channel Dispatcher service. * Account::allowedPresenceStatuses() now has fallbacks to include available and offline when that makes sense. * Removed some more private symbols from the shared library, resulting in slightly faster load times. * Deprecated ConnectionCapabilities contact search related methods with singular names and added plural versions of them, for API consistency. * Contacts publish/subscription state updates for removed contacts are only signalled after the ContactManager::allKnownContactsChanged signal is emitted. Fixes: * Redundant Contact::avatarDataChanged() emissions. * Connection::becomeReady() never finishing in state Connecting, which for example prevents handling ServerAuthentication channels. NOTE: any code incorrectly relying on the old buggy behavior of becomeReady() only finishing once the connection goes Connected or Disconnected may need adjustment. * Linking errors referencing the QtXml library. * Spec-incompliant building of Client names when uniquifying is requested from ClientRegistrar. * Sensitive data in Account parameters being included in debug logs. Regards, Andre ___ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy
