Thanks, Volker, for the answer. Will think more and try it in action provider<->server<->analytic app to see how it works to better understand.
However still have some concerns: if I want to get such id from the server I need to write separate logic, API, etc. I see that we can create, subclass, extend data sources. However Provider is not such extendable, and sometimes it is not very convenient to use it in some external, non-KDE applications. Could we ask You or participate in development to make it more modular, extendable, flexible and maintainable, i.e. to follow Single Responsibility Principle and other S.O.L.I.D principles. Provider does to many things:
- aggregate data sources
- network communications
- schedules submissions
- writes audit log (log text file could be changed to DB for example if moved to separate class)
- writes setting (QSettings could be changed to SettingsDatabase class)
- doubles some data sources
Could we move some of these to separate abstractions, like: network, log, settings. For example if we want to change/extend some network communication logic with the server:
- get unique ID from the server
- change API, url path, etc
- add authentication, etc
Think network logic could be moved to separate abstract class, layer, so we can extend it or replace by our own. If we could do such job we would be very grateful You for that because it is not very good to reinvent the wheel - develop new telemetry library or framework. :)
Also I created my own dialog to view collected statistics from user side (frontend) to replace AuditLogBrowserDialog. As I saw in the sources, I can attach AuditLogUiController to my dialog and view information stored in *.log files. However it is not connected to Provider and I can't see current raw statistics. I found such possibility in the code, however it is not documented and not very beautiful as ProviderPrivate::jsonData() is hidden by PIMPL-pattern implementation for some reason:
// Show JSON statistics
Could we add jsonData() call result to AuditLogUiController and AuditLogEntryModel? Also why not to make jsonData() public?
11.03.2018, 10:48, "Volker Krause" <vkra...@kde.org>:
I've added some more details about this to the docs:
As you are not bound by the KDE telemetry policy you can add a custom data
source with a unique id, that should be straightforward to implement.
Historic data is by default not submitted, but custom data source have the
ability to build a history locally, and submit that in whatever form they