On Sunday, 11 March 2018 16:23:33 CET Aleksey Kontsevich wrote: > 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
Why do you need to retrieve a unique id from the server? That seems unnecessarily complicated for what could be done by a QUuid locally, no? > change API, url path, etc See also my still open questions on your REST API and where to do the translation between what KUserFeedback expects to what you have on your backend in the previous discussion with Tino and Tuukka. > add authentication, etc What do you want to authenticate with? If this is about using real user accounts you are getting close to GDPR territory, no? > 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. :) I'm fine with changing things, I'm just still trying to understand the requirements correctly :) > 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: > QByteArray jsonData; > QMetaObject::invokeMethod( > m_feedbackProvider, "jsonData", > Q_RETURN_ARG(QByteArray, jsonData), > Q_ARG(KUserFeedback::Provider::TelemetryMode, > KUserFeedback::Provider::DetailedUsageStatistics)); > // Show JSON statistics > > ui->textBrowser->setPlainText(QString::fromUtf8(jsonData.constData())); The audit log features is for users to inspect everything that has been sent so far. For the current data that would be sent going forward, see FeedbackConfigWidget/FeedbackConfigUiController, that's probably the more interesting UI part. Regards, Volker > 11.03.2018, 10:48, "Volker Krause" <vkra...@kde.org>: > I've added some more details about this to the docs: > https://commits.kde.org/kuserfeedback/4c685a70afcf6ba58ce4455e88ef339c6d9e37 > b8 > > 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 > want. > > Regards, > Volker
Description: This is a digitally signed message part.