In D20160#520396, @vkrause wrote:In D20160#520151, @vitalyf wrote:In D20160#448449, @vkrause wrote:Apart from that I think we only need to resolve the minimum Qt version issue before integrating this.
Hi @vkrause, Any luck here?
If I'm not mistaken this patch still raises the required Qt version from 5.5 to at least 5.9, right? If so that still needs to be addressed (as in: restore Qt 5.5 compatibility) before this can be integrated. I'm sorry if that wasn't clear.
- Queries
- All Stories
- Search
- Advanced Search
Feed Advanced Search
Advanced Search
Advanced Search
Aug 28 2019
Aug 28 2019
Aug 27 2019
Aug 27 2019
In D20160#448449, @vkrause wrote:Apart from that I think we only need to resolve the minimum Qt version issue before integrating this.
Apr 15 2019
Apr 15 2019
Apr 12 2019
Apr 12 2019
DefaultDataSubmitter is set by default. I also changed "#pragma once" to include guards.
Apr 11 2019
Apr 11 2019
I've fixed the test and also removed 5.13 introduced code.
Apr 10 2019
Apr 10 2019
In D20160#447290, @vkrause wrote:Conceptually and structurally I think this is getting there, but we need to address the minimum Qt requirement :) Right now even 5.12 isn't enough due to the Q_DISABLE_COPY_MOVE it seems, so I can't easily test this here.
Apr 9 2019
Apr 9 2019
In D20160#446480, @vkrause wrote:In D20160#443341, @vitalyf wrote:Regarding redirects handling, I suggest just use mechanism introduced in Qt 5.6. That one I already implemented, but this of course will be moved to the second class which is more specific.
5.6 or 5.9? As mentioned before with GammaRay using this an needing 5.5 support this is a problem. If we are talking about 5.6 I could possibly just update the snapshot GammaRay uses to before this change and hope we wont need another update before GammaRay doesn't support 5.5 anymore. For 5.9 this is more of an issue though.
Apr 4 2019
Apr 4 2019
In D20160#443336, @vkrause wrote:In D20160#443328, @vitalyf wrote:In D20160#443326, @vkrause wrote:Sharing common bits of network code makes perfect sense of course. Not knowing your backend interface makes it hard to suggest specifics though. What is the main difference to the current interface, ie. which parts do you actually need to be able to control?
Only requests, I would say. The new class should look like this:
enum class SubmissionOption { ... } class BaseDataSubmitter : public AbstractDataSubmitter { public: void submit(const QByteArray &data) const final; SubmissionOptions options() const; void setOptions(KUserFeedback::SubmissionOptions options); protected: virtual QNetworkRequest probeRequest() const; virtual QNetworkRequest dataRequest() const = 0; // ... };Basically, what I propose is to split AbstractDataSubmitter I implemented before, to two classes: more abstract interface and more specific implementation to keep common and useful functionality. If a user need to implement something specific, he could take the top-level interface class AbstractDataSubmitter, if it would be enough to just slightly configure requests, he could take BaseDataSubmitter (or we can name it QtBasedDataSubmitter).
Or maybe [Abstract]RestDataSubmitter? As you said earlier, any implementation is likely based on Qt :) Having virtual methods to get the requests makes sense, and is a manageable public interface (which I assume is what this will be, as your implementation will be external, right?). I'm wondering though if we can avoid the submission options.
That contains 3 options from what I can see:
- add mimetype and payload size header fields: if you need to customize that you could adjust it in the xRequest() methods too, right? Same as e.g. adding an API key header. I don't like these options as they well overly specific, and I don't even think our current backend cares much about those headers being present or not, ie. if you need something specific for your backend, maybe we can just set that as default?
- enabling the probe request: that makes more sense on first sight, however the reason why this was added is that redirects on POST is apparently somewhat undefined in the HTTP standard, and quite inefficient as you send the full payload just to learn you have to do so again. And redirection support is something you most likely want in long-term deployments, to be able to adjust your infrastructure on the server over time. If you want to avoid that, how are you going to deal with this issue instead?
In D20160#443326, @vkrause wrote:In D20160#443321, @vitalyf wrote:@vkrause, I'm thinking about adding one more basic class for sending data. This class will inherit the interface we discussed above, but also will provide some common utilities based on QtNetwork things (I think, it should be functionality, we decided to remove from basic class). I propose name like "BaseDataSubmitter" or "QtBasedDataSubmitter". We need this, to avoid massive code duplication.
What do you think about this idea?Sharing common bits of network code makes perfect sense of course. Not knowing your backend interface makes it hard to suggest specifics though. What is the main difference to the current interface, ie. which parts do you actually need to be able to control?
@vkrause, I'm thinking about adding one more basic class for sending data. This class will inherit the interface we discussed above, but also will provide some common utilities based on QtNetwork things (I think, it should be functionality, we decided to remove from basic class). I propose name like "BaseDataSubmitter" or "QtBasedDataSubmitter". We need this, to avoid massive code duplication.
What do you think about this idea?
Apr 2 2019
Apr 2 2019
So, you propose interface like this:
class AbstractDataSubmitter : public QObject { public: ~AbstractDataSubmitter() override;
In D20160#442095, @vkrause wrote:I like the general approach of factoring out the data submission, and making that an extension vector. I am however unsure about how that interface should look like. This now exposes very fine grained switches (like setting of certain HTTP headers) and protocol internals (the probing GET before POSTing, to support redirects), which feels like we are doing this at a too low level. I can't imagine the presence of a content length header being the decisive difference in practice for example.
Shouldn't this rather be on the level of "here's a JSON document, a server URL and product id, submit it and let me know how that went"? That is, leave all the details of HTTP headers, probing requests, etc to the actual implementation? One could even argue that no QtNetwork usage should leak through that interface, even if that is probably unnecessarily extreme.
Apr 1 2019
Apr 1 2019
In D20160#441351, @vkrause wrote:Didn't have time to look into (1) and (2) yet, but the reason for (3) is compatibility all the way back to Qt 5.5, which is oldest version still supported by GammaRay.
Mar 19 2019
Mar 19 2019
In D19882#434465, @vkrause wrote:Huh? I must have misclicked, sorry, this was supposed to be approved :)
@vkrause, What kind of changes are required?
Mar 18 2019
Mar 18 2019
"Active" state is not reset in between data submissions anymore.
Also fixed unit test for this piece of functionality.
Mar 15 2019
Mar 15 2019
"Active" state is stored in the settings now.
Also added unit tests covers new functionality.
In D19757#431448, @vkrause wrote:I had option (2) in mind initially, assuming that this doesn't hurt even for scenarios where this functionality isn't needed. It would also be consistent with how the current settings are persisted, avoiding the surprise that disabled elements get automatically activated again if you don't implement persistence manually in your application. (1) would achieve the same thing I think, so I'd be ok with that too. I just don't like option (3) :)
Changed the method name and added unit test covers lookup functionality.
In D19757#431102, @vkrause wrote:Do we need to persist this setting?
Mar 14 2019
Mar 14 2019
Slightly changed documentation format to match code around
Mar 13 2019
Mar 13 2019
Some accidentally renamed parameters restored back
vitalyf retitled D19725: Add a method to get a short name of a telemetry mode from Add FeedbackConfigUiController to the headers for installation to Add a method to get a short name of a telemetry mode.
In D19725#430145, @vkrause wrote:The change makes sense, but the commit message seems unrelated :)
vitalyf retitled D19725: Add a method to get a short name of a telemetry mode from Added FeedbackConfigUiController to the installation script to Add FeedbackConfigUiController to the headers for installation.
Mar 7 2019
Mar 7 2019
In D19505#426259, @vkrause wrote:If you don't have commit rights yet, I can land this for you, but I'd need an email address to properly attribute it.
Mar 6 2019
Mar 6 2019
In D19505#425812, @vkrause wrote:I can't seem to reproduce this here, nor can the CI apparently. Also, those two header files are in different folders here...
Hm, are you using a different build system by any chance?
In D19505#425264, @vkrause wrote:Does this break the build for you? Since this header is technically from a different library, the use of the angle brackets doesn't seem wrong to me...
Mar 4 2019
Mar 4 2019