12.03.2018, 11:25, "Volker Krause" <vkra...@kde.org>: > 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?
For server to control it gives unique ID from same pool to every machine connected. >> 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. Actually I took above code from FeedbackConfigWidgetPrivate, line 72-74. As I mentioned such structure not very convenient and clear: good to have single model and single controller for the statistics: current and archived. Best regards, Aleksey.
