Telemetry Policy

[Ben Cooksley]

On Mon, Aug 14, 2017 at 11:40 PM, Volker Krause <vkrause at kde.org> wrote:
> I agree on the proposed wording changes, so focusing on your technical points
> below.
>
> On Monday, 14 August 2017 11:53:17 CEST Ben Cooksley wrote:
>> I've got two technical notes here:
>>
>> 1) All products should fetch details on where to submit telemetry data
>> from an online configuration file similar to
>> https://autoconfig.kde.org/ocs/providers.xml
>>
>> This would give us the capacity to version the telemetry server api,
>> and potentially even "kill" telemetry submissions from older
>> application versions if needed.
>>
>> 2) No software product should use the QNetworkAccessManager family of
>> classes due to known defects in it's operation within some versions of
>> Qt which cause infrastructure problems.
>
> The current implementation uses QNAM, but actually has code to handle HTTP
> redirects correctly (with unit test coverage), I assume that's the issue you
> are referring to? This also has been tested all the way back to Qt4.8 as part
> of the existing deployment in GammaRay.

That's one of the considerations yes. I'm hopeful that nothing else in
it will be found to be broken behaviour wise but have much more faith
in KIO here.

>
> I don't mind adding the extra indirection with the configuration file, although
> just from the XML I don't see yet what that would provide beyond HTTP
> redirects. Are there certain information (e.g. the app version) passed already
> as part of the request for the configuration file? Or can there be conditional
> aspects not currently present in the above example?

The extra indirection is basically to give us the option to shift the
endpoint elsewhere at some point without having to keep the old one
alive even as a redirect.

I'm also concerned that we could potentially run into issues if the
system doesn't do any GET requests. From what I recall unless the
server and client support a specific RFC then redirecting POST
requests isn't something one can rely on here (your code might handle
this properly, I certainly wouldn't trust QNAM to do so given their
stance on optional behaviour in HTTP RFCs)

>
> Regards,
> Volker

Thanks,
Ben