KUserFeedback UUID question

[Aleksey Kontsevich]

12.03.2018, 11:25, "Volker Krause" <vkrause at 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.