[Bug 26785] PendingMessagesRemoved signal should be more informative

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=26785





--- Comment #3 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2010-03-01 08:22:04 PST ---
(In reply to comment #2)
> Being able to access the message-token, when present, I think would allow
> Clients to retrieve less data or in a faster way.

In practice, there are basically no protocols with a guaranteed-globally-unique
token in the messages (i.e. message-token). Even in protocols with such a
token, we're unlikely to be able to trust it, because a sender might
intentionally use a non-unique value in order to confuse us.

> I also understand that it's a stable signal and it's not easy to amend it.

Yeah, the question isn't "can it be done?" (it can - as you say, the CM still
has the message in memory at this point), but instead "is adding an optional
PendingMessagesRemoved2 signal with more info worthwhile?" (the cost of which
is that it adds more code paths and makes our API more confusing, and for a
significant length of time, clients will still need to cope with its absence).

> An observer wants to keep track of the receiving and ACK times for every
> message it can.

This can't reliably be done across an observer exit. Channels can't necessarily
be matched by object path over time, because if a channel has closed, an
unrelated channel, possibly going to a different contact, might appear at the
same object path (in practice, this is likely to happen whenever a Connection
disconnects and is replaced by a new one).

In an observer that hasn't exited, you can watch TpChannel::invalidated to see
whether the channel has closed (if it hasn't, then its object path can't have
been re-used).

Does Tpl store object paths in its database? If it does, perhaps it shouldn't.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.