On 25 September 2016 at 18:06, Alessandro Pasotti <[email protected]> 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 _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
