| Summary: | Make the old chat history of Empathy-pre-TPL accessible | ||
|---|---|---|---|
| Product: | Telepathy | Reporter: | Cosimo Alfarano <cosimo.alfarano> |
| Component: | logger | Assignee: | Cosimo Alfarano <cosimo.alfarano> |
| Status: | RESOLVED FIXED | QA Contact: | Telepathy bugs list <telepathy-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | danielle, guillaume.desmottes |
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
It's possible that Empathy should actually be responsible for the migration. Not sure. Currently it is working that way: A LogStore has two properties, readable and writable. The LogManager can register agaisnt more than one LogStore. When a signal is received, tpl_log_manager_add_message is called, which will send the LogEntry message to every writable=True LogStore. When a query is received, the log manager will send and return results for every LogStore with readable=True. defaults: readable=True, writable=False. Consequences: - each client using libtelepathy-logger (ie Empathy), when initialized the TplLogManager instance, add to it its own LogStore. In case of empathy, it is sufficient to change the name property for the LogStore, which make the LogStore to look into .local/share/<Name>/logs. name='Empathy' in Empathy's case. It's a different matter for DBus queries, which won't see any LogStore added to the client TplLogManager instance (which is local to the client's process), since the DBus query will query the telepathy-logger process LogManager. It will result into different result sets, since the query database is different. Currently empathy do not uses DBus for the GetRecentMessages(), but directly libtelepathy-logger, so Empathy has no problem. Probably to solve this problem, a proper plugin system would be OK, but not a quick think to do though Some notes about 'log base migration' vs. 'TPL read-only import' for the Empathy old log base, after a chat with Cassidy:
Migrating from ${XDG_DATA_HOME}/share/Empathy to ${XDG_DATA_HOME}/share/TpLogger
might incur in race conditions in case data is moved/copied while the service is running, or lost of data if the service is temporarily disabled.
Adding a readable=Tue writeable=False logstore pointing to the old Emapthy log base dir at TplLogManager init time is the safest way to handle reaces:
- in case an old version of Empathy (not TPL) is still used while TPL is running, Empathy will use the old repository, which being not writeable wouldn't result in problem for TPL.
- in case a TPL enabled version for Empathy is used, empathy will be able to use the library or DBus APIs freely, automatically accessing the old 'previous conversation.'
A third case is interesting:
- not-TPL-Empathy is used in conjunction to TPL for a while, resulting of duplicates entries in Empathy and TPL log stores. Then Empathy is upgraded to the TPL enabled version.
What TPL should do with the duplicates?
Probably merging them directly in the LogManager is OK.
Probably a filed for the LogStore name in TplLogEntry should be added as a list of LogStores names in which the entry appears, so that a client that needs this information will use it. g_list_lenght(log_store_name) > 1 means the log is duplicated.
Added in b4c417233bb8feeb3c0dfc6ce7969f2252c6c3e2 |
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.
Empathy keeps its logs into ${XDG_DATA_HOME}/share/Empathy. The preferred way to make the old Empathy messages accessible to TPL is to add ${XDG_DATA_HOME}/share/Empathy as storing location for a new instance of TplLogStoreEmpathy, this instance will be read-only (i.e., logstore->add_message = NULL) so that it will be untouched but still accessible for historical reasons.