[Bug 26785] PendingMessagesRemoved signal should be more informative

[bugzilla-daemon at freedesktop.org]

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





--- Comment #4 from Cosimo Alfarano <cosimo.alfarano at collabora.co.uk>  2010-03-01 10:56:55 PST ---
> 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.

>From this point of view, TP should create its own unique token or give the
possibility to clients to obtain a trustable and unique token, even if its
uniqueness is only local to TP (ie not passed by the protocol).

A DBus method, ie GetLocalMessageToken(...), might be a good alternative, if
adding a field to Message_Part[0] is not doable.
It would allow any client that needs it to 'tokenize' a message.

Currently TPL is using a similar function, for internal use, hasing the triple
(channel path, pending msg id, timestamp).
The triple should uniquely identify, in TP at any time, a message.

The point is that not always I can have such triple (ie
RemovedPendingMessages). Having it would allow me not to store any channel path
to identify messages.

Adding a Signal RemovedPendingMessageToken might be added passing this token
instead of the message_id. It would have the same function without changing the
current interface.
The point is, all the CM should implement it to be useful, if just one won't
it'd be completely useless.
Unless something else could raise this signal instead of CMs. I don't know if
it's doable.

Unique and trustable message-token feature is quite important to Observers,
which should be able to trust a token to be unique, in order to not discard not
logged messages and to discard already logged messages properly.

If malice in protocol's token is considered, an alternative should be given.

> 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).

what key should I use instead?

> 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).

That's right, and it helps to keep the DB clean dueing the normal Observer's
lifecycle.
But there is a case in which I cannot find any solution to understand if a
channel is or is not the same:

(Note that TPL also retrieves ant already open channel and hooks their signals
as well)

When TPL restarts after a crash (yep, shouldn't happen, but I need to preserve
consistency considering it as a possibility) I don't know if it crashed because
of a system crash (ie TP chrased as well) or because just the process did.

In the first case, a channel path might be reused but pointing to different
channel instance before the restart, in the second case it might be that the
channel, while the restart occured, never closed and reopened but actually is
the same instance.

Since there is no way to understand what really happened, the described race
scenario may occur.

Issues are raised when stateful processes try to obtain information from TP,
which is completely stateless, AFAIK.


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