We need to find and resume logging existing channels when the Observer starts.
A beginning path is at http://git.collabora.co.uk/?p=user/kalfa/telepathy-logger.git;a=shortlog;h=refs/heads/open-channel-retrieving It currently calls ObserveChannels for every channel found, the channel-factory will filter it out later. Would be interesting (and faster) if there were an API using the channel-filter to send to ObserverChannels only the selecte ones. TPL now also needs a way to understand if a pending message has already been logged. It's a rare case, but currently if TPL stops at time T1 and starts again at time T2, any message contained in the pending message queue at T2 which was there also at T1 will be logged twice.
> Would be interesting (and faster) if there were an API using the channel-filter > to send to ObserverChannels only the selecte ones. There is an open bug for this, I think, but I can't find it. > TPL now also needs a way to understand if a pending message has already been > logged. > > It's a rare case, but currently if TPL stops at time T1 and starts again at > time T2, any message contained in the pending message queue at T2 which was > there also at T1 will be logged twice. Maybe we should log the message-token (which comes from the Messages interface -- http://telepathy.freedesktop.org/spec/org.freedesktop.Telepathy.Channel.Interface.Messages.html#org.freedesktop.Telepathy.Channel.Interface.Messages.Message_Part) and use that to search recent messages for duplicates? Could also be used to find duplicates between log stores, e.g. Empathy's and the Loggers (if Empathy was logging them too).
The message-token is a good idea for finding duplicates in searches or as a general way to check if a message has been already logged, to be added to the current API. The LogEntry has already a logid field, which can be updated with this value, if guaranteed to be unique in TP. The use of this API to solve the duplicate logging for pending messages I'm afraid it's too heavy, since it will be run at startup time, I'd like it to be as much faster as possible. #26647 is about that and offers a solution which should cover the same cases in a faster way. It involves just a bit that I'd like to avoid: the persistence of the list, but probably it's better than a logstore->search_token for each message in the queue. After all the presisted list will be read just once and written just once per process' lifecycle. For the rest it's faster than a LogStore query and should work since AFAIK msg-id are unique along the channel dispacher life time, which is what is important in relation to pending messages.
This was accidentally filed again. Making a dup of the _newer_ bug because that has the review on it. *** This bug has been marked as a duplicate of bug 26741 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.