[Qgis-developer] QGIS Server 3.0 roadmap

[René-Luc Dhont]

Hi Devs,

To enhance the discussion, David Marteau @dmarteau, has updated the QEP: 
QGIS Server Services as plugins like providers with Proposed solution.
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/74

Feedback is welcomed.

René-Luc

Le 27/09/2016 à 09:19, Nyall Dawson a écrit :
> 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