KUserFeedback UUID question

[Volker Krause]

On Monday, 12 March 2018 11:06:59 CET Aleksey Kontsevich wrote:
> 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.

You could still do that as part of the custom data source, the request does 
after all only have to happen once, rather than on every submission.

> >>  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.

That depends on how your UI looks like, the reason this is separate currently 
are:
- data source might be added/modified/removed over time
- not all applications might want to use the audit log feature in the first 
place.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20180312/5c265a04/attachment.sig>