<div>Thanks, Volker, for the answer. Will think more and try it in action <strong>provider<->server<->analytic app</strong> to see how it works to better understand.</div><div> </div><div>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 <span style="color:#800080;"><strong>Provider</strong></span> 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 <em lang="en" style="font-style:italic;">Single Responsibility Principle</em> and other S.O.L.I.D principles. <span style="color:#800080;"><strong>Provider</strong></span> does to many things: <em> </em></div><ul><li>aggregate data sources</li><li>network communications</li><li>schedules submissions</li><li>writes audit log (log text file could be changed to DB for example if moved to separate class)</li><li>writes setting (<span style="color:#800080;"><strong>QSettings</strong></span> could be changed to <strong><span style="color:#800080;">SettingsDatabase</span></strong> class)</li><li>doubles some data sources</li></ul><div>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:</div><ul><li>get unique ID from the server</li><li>change API, url path, etc</li><li>add authentication, etc</li></ul><div>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. :)</div><div> </div><div>Also I created my own dialog to view collected statistics from user side (frontend) to replace <span style="color:#800080;"><strong>AuditLogBrowserDialog</strong></span>. As I saw in the sources, I can attach <span style="color:#800080;"><strong>AuditLogUiController</strong></span> to my dialog and view information stored in *.log files. However it is not connected to <span style="color:#800080;"><strong>Provider</strong></span> 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 <span style="color:#800080;"><strong>ProviderPrivate::jsonData()</strong></span> is hidden by <strong>PIMPL</strong>-pattern implementation for some reason:</div><div> </div><div><blockquote><div>        QByteArray jsonData;</div><div>        QMetaObject::invokeMethod(</div><div>            m_feedbackProvider, "jsonData",</div><div>            Q_RETURN_ARG(QByteArray, jsonData),</div><div>            Q_ARG(KUserFeedback::Provider::TelemetryMode, KUserFeedback::Provider::DetailedUsageStatistics));</div><div> </div><div>        // Show JSON statistics</div><div>        ui->textBrowser->setPlainText(QString::fromUtf8(jsonData.constData()));</div></blockquote><div> </div><div><br />Could we add <strong><span style="color:#800080;">jsonData()</span></strong> call result to <span style="color:#800080;"><strong>AuditLogUiController</strong></span> and <span style="color:#800080;"><strong>AuditLogEntryModel</strong></span>? Also why not to make <strong><span style="color:#800080;">jsonData()</span></strong> public?</div><div> </div><div>Thanks!</div></div><div> </div><div>-- </div><div>Best regards,</div><div>Aleksey</div><div><strong>Linked<span style="color:#ffffff;"><span style="background-color:#0000ff;"> in </span></span></strong> <a href="https://www.linkedin.com/in/alekseykontsevich">https://www.linkedin.com/in/alekseykontsevich</a></div><div> </div><div> </div><div>11.03.2018, 10:48, "Volker Krause" <vkrause@kde.org>:</div><blockquote type="cite">I've added some more details about this to the docs:<p><a href="https://commits.kde.org/kuserfeedback/4c685a70afcf6ba58ce4455e88ef339c6d9e37b8">https://commits.kde.org/kuserfeedback/4c685a70afcf6ba58ce4455e88ef339c6d9e37b8</a><br /><br />As you are not bound by the KDE telemetry policy you can add a custom data<br />source with a unique id, that should be straightforward to implement.<br /><br />Historic data is by default not submitted, but custom data source have the<br />ability to build a history locally, and submit that in whatever form they<br />want.<br /><br />Regards,<br />Volker</p></blockquote>