-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Clean WMS service #4019
Conversation
dmarteau
commented
Jan 18, 2017
•
edited
Loading
edited
@elpaso any objection to merge ? |
@rldhont not at all, I've just added some minor comments |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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" ) ) ) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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.
b68e1af
to
71564a2
Compare
- 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
@elpaso speaking about optimisation: is there something planned about Q_FOREACH expression ? |
I'd ask @nyalldawson and @m-kuhn how to proceed, if I get it right we should eventually replace Q_FOREACH. |
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 ( 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. |
generally speaking I'm in favor to reduce the use of QT dependent operators. |
see feature request qgis#4019