[Qgis-psc] QGIS Server (online) Developer Meeting

[Alessandro Pasotti]

On Mon, Jun 15, 2020 at 1:12 AM Tim Sutton <tim at kartoza.com> wrote:

> Hi
>
> Thanks for raising this Ale.
>
> On 10 Jun 2020, at 11:38, Alessandro Pasotti <apasotti at gmail.com> wrote:
>
> Hi,
>
> Following the discussion on the dev mailing list
> https://lists.osgeo.org/pipermail/qgis-developer/2020-June/061470.html
>
> we (I launched the idea and Andreas was happy with it) were thinking
> of organizing an online developer meeting targeted at QGIS Server.
>
> The topics should IMO be:
>
> 1. define (and possibly write it down) the QGIS server project goals:
> what kind of product we want to develop (we might well decide that
> what we currently have is all we need)
> 2. discuss the "market share" and the "competitors" (yes: I hate this
> marketing speech but I cannot find any better in english, sorry) and
> what QGIS Server lacks
> 3. how we can make QGIS Server the world conqueror it deserves to be
>
>
> Sounds good, and I wouldn’t worry about the marketing speech, your intent
> is clear.
>
> This is an initial list of potential sub-topics for 2. about what we
> might currently miss:
>
> - vendor features (CQL, CSS)?
> - performances?
> - scalability (includes shared caching)?
> - standard compliance?
> - missing protocols (WPS...)?
>
>
> For WPS maybe invite 3Liz along as I know they built a WPS server for QGIS
> once….
>
>

Sure, they are of course at the top of my list as Renè is one of the top
contributors to the server.



> - documentation/examples?
> - ease of deployment/maintenance (includes containers, supported OS etc.)?
> - security auditing?
> - admin panel?
> - programmability (I bet it's not a miss) ?
> - customization (includes templating) ?
> - plain marketing?
>
> Can we call it an official QGIS.org meeting?
>
>
> Is it worth bringing the web clients into the discussion? For me the two
> things are somewhat linked in that it is hard to deploy a server instance
> while rolling out your own web client that properly takes advantage of all
> the capabilities of QGIS Server.  I know that complicates the discussion so
> feel free to keep that for another time.
>

My opinion is NO (but this topic can be of course put in the meeting
agenda).

I think we need to focus on the server and not on the client, to be honest
I've always been against including the clients (QWC1 and QWC2) in QGIS.
There are plenty of capable developers and integrators out there that
provide client solutions based on OGC standards (+ QGIS vendor extensions),
what is our duty for the server is IMO to:
- make sure the server is fast, reliable, and modern
- provide OGC compliant APIs and services
- provide vendor APIs (getPrint & C.) to allow a.m. parties to create great
web clients
- provide documentation and examples for server programming and
customization i.e. help the developers and integrators to create their own
clients and applications based on the server code



> Also metalling and metabuffering are IMHO pain points that require
> dropping Mappoxy in front of a QGIS server whenever we are doing tiled
> requests.
>
>
>

I'm also -1 on this: provided that any time you want tiles you also want
some kind of customized caching I have the feeling that this needs to be
tailored to the application need and that we should not try to reinvent the
wheel by implementing this tier of caching into the server core, at least
for now, I'm not saying it won't eventually come under the server radar.

Again: focus on the server core and make it a winner, then we can think
about adding modules, perhaps as plugins or API modules.

As for meta tiles, I think that we have something in core now:
WMSTileBuffer.


>
> I would need some help with the definition of the program and the
> organization, even if it's online.
>
>
>
> Given that the discussion will probably dissolve into people like me above
> adding Wishlist features it would be good to figure out what the concrete
> goal of the meeting would be. One idea would be a ranked list of pain
> points and some kind of costing (maybe taken offline) to take care of the
> top 3 items in the list.
>
>
>
> What do you think?
>
>
> +1 from me. Maybe we can keep the organisation simple and have an online
> meeting on Jitsi / Zoom / whatever at an announced time with an open
> invitation to the developer list?
>
>
I was actually thinking of making the meeting invitation public in the
developer mailing list and this is probably the way to go, I'm just a
little scared of having too many people and adding too much entropy.
I'd like to keep the group small but not too small, I think 12-20
(speaking) people is the max for this kind of online meeting, but I'm open
to proposals.



> For my 2c I am very -1 on the idea raised of getting rid of QGIS server
> and would rather we use funds to help bring it on par with other servers,
> at least in terms of configuration management. Having spent the last few
> months editing SLD files in GeoServer (much as I love GeoServer) I am
> really conscious of how much more efficient life is when we can design our
> maps in QGIS and publish them directly without fiddling around in SLDs (or
> mayflies).
>


Yeah, I think we all agree on that. Besides that the assumption about the
zero sum game was plain wrong: I've worked on countless server issues that
had roots in the QGIS core libraries.

Cheers

-- 
Alessandro Pasotti
QCooperative:  www.qcooperative.net
ItOpen:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20200615/326f8fd1/attachment.html>