Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clean WMS service #4019

Merged
merged 1 commit into from
Jan 19, 2017
Merged

Clean WMS service #4019

merged 1 commit into from
Jan 19, 2017

Conversation

dmarteau
Copy link
Contributor

@dmarteau dmarteau commented Jan 18, 2017

- Remove "transitional" code
- Remove duplicated code (or functionaly equivalent code)
- Remove dead code
- Sanitize error checking
- Ensure correct build with HAVE_SERVER_PYTHON_PLUGINS not defined

@rldhont rldhont added the Server label Jan 18, 2017
@rldhont rldhont added this to the QGIS 3 milestone Jan 18, 2017
@rldhont
Copy link
Contributor

rldhont commented Jan 18, 2017

@elpaso any objection to merge ?

@elpaso
Copy link
Contributor

elpaso commented Jan 18, 2017

@rldhont not at all, I've just added some minor comments

Copy link
Contributor

@elpaso elpaso left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. I've just added some minor notes wanted to make sure that @sbrunner is fine about removing the conditional for the HAVE_SERVER_PYTHON_PLUGINS

@@ -27,15 +27,11 @@ namespace QgsWms
QgsMapRendererJobProxy::QgsMapRendererJobProxy(
bool parallelRendering
, int maxThreads
#ifdef HAVE_SERVER_PYTHON_PLUGINS
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure: @sbrunner what do you think?
BTW, always make sure that id builds with plugins disabled.

Copy link
Contributor Author

@dmarteau dmarteau Jan 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elpaso If HAVE_SERVER_PYTHON_PLUGINS is not defined then accessControl is an opaque type and the pointer returned by the serverInterface in set to null: by doing this we can safely remove all conditionals on parameter list (but not those associated to specific code execution).

My wish is to remove all HAVE_SERVER_PYTHON_PLUGINS defines from parameters list: they are ugly and they require to have them at every invocation of the method or function.

Copy link
Contributor Author

@dmarteau dmarteau Jan 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elpaso checked that build is ok with plugins disabled. Removed HAVE_SERVER_PYTHON_PLUGINS defines from parameters list and fixed other defines accordingly.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @dmarteau, the refactoring is looking great!


if ( !parameters.contains( QStringLiteral( "SLD_VERSION" ) ) )
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not an expert here, but I suspect that if the function has an overload for QLatin1String it would be faster here. (see: https://woboq.com/blog/qstringliteral.html)
Same in other points of the code.

Copy link
Contributor Author

@dmarteau dmarteau Jan 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I read the post: the assertion is very vague and gives no hints about wich kind of algorithm is impacted by the choice of one are another type: In our case it would be the computation of the order relation between two strings ( it's a QMap ). I would bet that the fastest case would be when the compared strings are of the same type.
Afaik: nothing can prevent parameters to be utf-8 so if had to choose a type I would use the most common case everywhere.

Copy link
Contributor Author

@dmarteau dmarteau Jan 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@elpaso Afaik: QMap has no specific overload for the contains method.

QDomProcessingInstruction xmlDeclaration = doc.createProcessingInstruction( QStringLiteral( "xml" ),
QStringLiteral( "version=\"1.0\" encoding=\"utf-8\"" ) );

// Appond format helper
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

append

elem.appendChild( dcpTypeElement.cloneNode().toElement() ); //this is the same as for 'GetCapabilities'
requestElement.appendChild( elem );

if ( projectSettings ) //remove composer templates from GetCapabilities in the long term
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean with the comment? Do you want to add a different REQUEST for getProjectSettings ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know: these are original comments. Functionaly nothing has changed, I have only restructured parts of the original code.

@dmarteau dmarteau force-pushed the wms_cleanup branch 2 times, most recently from b68e1af to 71564a2 Compare January 18, 2017 22:35
    - Remove "transitional" code
    - Remove duplicated code (or functionaly equivalent code)
    - Remove dead code
    - Sanitize error checking
    - Ensure correct build with HAVE_SERVER_PYTHON_PLUGINS not defined
@rldhont rldhont merged commit 53752ba into qgis:master Jan 19, 2017
@dmarteau
Copy link
Contributor Author

@elpaso speaking about optimisation: is there something planned about Q_FOREACH expression ?
see https://www.kdab.com/goodbye-q_foreach/

@elpaso
Copy link
Contributor

elpaso commented Jan 19, 2017

I'd ask @nyalldawson and @m-kuhn how to proceed, if I get it right we should eventually replace Q_FOREACH.

@dmarteau dmarteau deleted the wms_cleanup branch January 19, 2017 09:46
@m-kuhn
Copy link
Member

m-kuhn commented Jan 19, 2017

Short: I am not sure.

Long: In this kdab post they advise to get rid of Q_FOREACH in favor of range-based for-loops (for item : container). There was a lot of controversy about it. Basically because the range-based-for-loop does require additional code to make use of implicit sharing in Qt containers. This makes porting harder and future usage less straightforward.

There is also an issue with our builtin astyle which should be updated before we should make use of range-based for-loops.

I appreciate if we stay close to the Qt style of coding and don't use deprecated concepts, but this is really a tricky one.

@luipir
Copy link
Contributor

luipir commented Jan 19, 2017

generally speaking I'm in favor to reduce the use of QT dependent operators.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants