[Development] QNetworkRequest autoDecompress public API review

Simon Hausmann simon.hausmann at digia.com
Tue Jun 18 16:54:54 CEST 2013


On Tuesday 18. June 2013 10.57.57 Jonas Gastal wrote:
> In working to solve [1] I created the change [2] which was approved for
> merging with a note of something for later fixing. However on trying to
> merge it CI showed what turned out to be an issue with the compression test
> that was related to Thiago's comment about the usage of #ifndef
> QT_NO_COMPRESS on QNetworkRequest.
> 
> Solving this in a satisfactory manner will require adding two new methods
> to QNetworkRequest, I'm thus asking for an API review. The methods would be:
> 
> bool autoDecompress() const;
> void setAutoDecompress(bool autoDecompress);

I'm not sure a verb is a good idea for a C++ property name, for example
req->autoDecompress() reads like it would _do_ something, when it's actually 
just a getter.

Does this have to be a standalone property, or would it fit into the Attribute 
enum? Alternatively, perhaps the "is" prefix could be used here?

Simon
 
> The default value for this would be true as that is what
> QHttpNetworkConnection does now, that way behavior will not change. The
> "Accept-Encoding" header would NOT be filled in by
> QNetworkRequest::addDefaultHeaders() but rather by the HTTP implementation
> in use(normally QHttpNetworkConnection) taking in consideration the
> following:
>  - If the users sets an "Accept-Encoding" header auto decompress is set to
> false;
>  - If the user has request auto decompress not be done, "Accept-Encoding"
> is not set;
>  - If the user has requested auto decompress be done, the HTTP
> implementation can set the "Accept-Encoding" to whatever values it can
> handle decompressing.
> 
> If the HTTP implementation doesn't support any compression(for example our
> internal implementation when compiled with QT_NO_COMPRESSS) and the user
> requests auto decompress, the HTTP implementation will just silently set
> "Accept-Encoding" as "identity" and the user will have lost some
> performance but his program will not break.
> 
> Does this look ok?
> 
> [1] http://bugreports.qt-project.org/browse/QTBUG-9463
> [2]https://codereview.qt-project.org/47395



More information about the Development mailing list