[Qgis-developer] QGIS Server 3.0 roadmap

[Nyall Dawson]

On 25 September 2016 at 18:06, Alessandro Pasotti <apasotti at gmail.com> wrote:
> Hi,
>
> I'm glad that Matthias's semi-serious threats to remove the server from
> source tree and Nyall's complaints have shaken the souls of the server
> people!

Apologies if I've caused any offence here - I was trying to give
constructive feedback and share some explanation as to the frustration
against maintaining server. I want to stress that i am VERY
appreciative of everyone who has put in effort into server & who has
funded time for devs to work on it.

I also applaud how well everyone has reacted to this, and all the
offers of time/development to improve server for 3.0!

Based on this reaction I think I'll go file a QEP to "rm -rf src/core"
and see if we can shake up some more developers ;)

>
> I insist that the server remains a first class citizen and a full featured
> tool within the QGIS project, but I understand that it should not be a brake
> for the core refactoring ,slowing down the amazing development that QGIS dev
> team is doing on the core and gui libraries.

I agree with this - I don't really want to see server pulled out of
core either.

As I mentioned over on the 3.0 api tracker, the biggest issue I see is
the way server loads projects and messes with the layer registry. I
understand this was probably a design decision made due to api
constraints, but now we've got the opportunity to fix the underlying
issues in core and avoid the messy workarounds in server.

I'd really appreciate it if someone more familiar with the server
architecture could summarise what's missing in core's project/layer
handling. I may be missing something, but would a something like this
help?:

- add a QgsProjectRegistry, with an instance attached to
QgsApplication. Change all the use of QgsProject::instance to
QgsProjectRegistry::currentProject().
- move QgsMapLayerRegistry from an instance to a member within
QgsProject. Core code would then use
currentProject()->mapLayerRegistry() instead of
QgsMapLayerRegistry::instance()
- server could directly pull projects from the registry (via some form
of generated project id) as required and access their map layer
registries directly

Nyall











>
>  I've just started a small WIP contribution aimed to solve a first issue
> (https://github.com/qgis/QGIS/pull/3528).
>
> I wonder what would be the better way to coordinate the efforts, gain in
> efficience and avoid duplication.
>
> This is a possible roadmap (suggestions welcome!):
>
> - start a QEP for the new server architecture (C++ plugins for the core
> services etc.) (@rldhont, can you take care of this?)
> - a list of prioritized issues (on the qgis hub?, on github? no idea here) (
> @nyall, @mkuhn: you know the new and old API very well,  if you could start
> creating a list of must-have, should-have, nice-to-have issues it would be
> very helpful)
> - create a formal (but completely open) dedicated team of developers and
> assign issues
> - possibly, meet periodically to coordinate the development
>
> Am I dreaming?
>
> --
> Alessandro Pasotti
> w3:   www.itopen.it