KUserFeedback UUID question

[Volker Krause]

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" <vkrause at 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

-------------- 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/ef4fe8de/attachment-0001.sig>