search

qgis / qgis4.0_api

Tracker for QGIS 4.0 API related issues and developer discussion
3 stars 1 forks source link

rm -rf src/server #63

Closed m-kuhn closed 7 years ago

m-kuhn commented 7 years ago

QGIS Server is not going to be removed but it's in strong need for a dedicated maintainer!

elpaso commented 7 years ago

A bit scary ;) What does it mean?

m-kuhn commented 7 years ago 
rm -rf src/server
rm                        remove
   -                      watch out: here come options!!
    r                     recursively
     f                    force
       src/               in the sourcecode
           server         the server

An alternative approach of someone taking responsibility for the code to migrate/refactor/maintain could be discussed ;)

elpaso commented 7 years ago

Thank you for the explanation, my question was not really about the syntax of rm but about the motivation behind the removal of server from QGIS source. Do you mean that QGIS Server is going to be removed from the QGIS project? I might have missed the thread but I've not seen much discussion on this topic in the mailing lists.

luipir commented 7 years ago

Mathias may you rephrase more explicitly the issue title and motivations. A good solution is to close this semi-cryptic issue, and open it again with a title that can warn correctly qgis server users and devs.

m-kuhn commented 7 years ago

On a more serious note, no, that's not directly meant. It's not going to be removed.

What's meant is that QGIS server is often neglected and in it's current state not sustainable. It's in need for a major refactoring and for a fully dedicated maintainer!

mdouchin commented 7 years ago

We should open a QEP and make an audit of what is good and what is wrong in current status. Many users rely heavily on QGIS Server, so we do not want to scare them. The goal is the refactor the server to make it sustainable

haubourg commented 7 years ago

@m-kuhn LOL, can somenone add following tags :+1:

elpaso commented 7 years ago

I fully agree that the server deserves more love. BTW I wouldn't say that the server is unmaintained, there is a small group of devs that is constantly taking care of it by backporting bug fixes, improving documentation etc. I'm pretty sure that we can create a team to ensure QGIS Server a bright future in the 3.0 branch.

m-kuhn commented 7 years ago

@elpaso I know and it is much appreciated!

strk commented 7 years ago

Does the server need to be in the same repo with the core or could it make sense to give it its own release cycle ?

m-kuhn commented 7 years ago

I would prefer to make it shiny and leave it where it is as a first-class-citizen.

mdouchin commented 7 years ago

we could redevelop it in pure Python and use QGIS api, and should get rid of old fcgi dependancy. We could develop a Python API to implement the OGC interface

nyalldawson commented 7 years ago

I can totally understand the frustration with the extra maintenance burden that server brings. It can be very frustrating when an otherwise well designed change in qgis core breaks something in server because server is misusing parts of the qgis api. To keep the lighthearted tone of this thread... whenever I see how server is handling project loading and the oddness it does with layer handling I can't help but think of this tweet:

QGIS server has some fantastic features, and I'm really happy to see the increased attention being given to making it stable and covered by regression tests.

...but I get very nervous when I see things like the number of potential security issues flagged by coverity against the server components. Online security (and server uptime!) is critical stuff and unfortunately instead of being the most maintained and thoroughly tested component of qgis it's unfortunate that server is currently lagging far behind with the attention that core/gui/app/plugins get.

Speaking totally from my own viewpoint... I think there's a two reasons why this is:

  1. there's not as many users-who-are-developers who use server. QGIS application has a constant stream of fixes and improvements coming from people who use it everyday and have motivation to see these changes happen. I don't think server has this same appeal and developer base. Eg - speaking again totally for myself, I don't use server and accordingly it gets none of my volunteer contribution time, but I use QGIS every day to make maps and accordingly I'm always pushing volunteer features & fixes. I would be very surprised if I'm the only one in this same situation.
  2. enterprises who are using server aren't contributing back upstream. Either they are end users who are using qgis server for free, or paying commercial companies for support but those companies are not contributing finances/fixes back upstream. (There's obviously a handful of exceptions here who are good open source citizens and regularly contribute back upstream.)

How can we fix this? I'm not sure... I think my first point above will always stand, but point 2 could be aided by further pushing the message that QGIS' survival is 100% dependent on people giving back to the community and not leaching off it.

3nids commented 7 years ago

If there are companies behind, it's a pity we didn't see a grant proposal for this then. Matthias' solution based on rm could be a good approach. Wait for a new implementation and ship 3.0 with or without server.

ocourtin commented 7 years ago

Hi alls,

Thanks Mathias to initiate this discussion !

A) Short answer:

Some key features on QGIS server should be kept, but the code and it’s design not. Means: rm -rf server/* + git pulls

B) Spirit:

The feature to keep is the WMS server based on .qgs symbology.

Ability for an end-user to deal with a rich symbology trough a GUI, and to get the really same output both with his desktop app and on the Web, worth. A lot.

And for same reason, as an extra WMS feature, PDF output (GetPrint), should also be kept.

On the other side, all the others features are not that meaningful, as they could already been provided (and better) by some others apps (WFS, TMS, SOS, Auth…)

So IMO a good target for 3.0 could/should be: WMS + SLD + FE + GetPrint PDF support

C) Few Architecture thoughts:

D) Oslandia could help on this QGIS Server 3.0 code effort.

Reactions welcome :)

elpaso commented 7 years ago

@mdouchin this is already possible, QGIS Server is built as a library and FCGI is just a tiny wrapper around QgsServer instance.

mdouchin commented 7 years ago

We should not drop all features not related to WMS. As it is very good to style layers in QGIS and have great WMS images with rich QGIS rendering, it is also very handy to configure the WFS within QGIS : fields to publish, aliases, use virtual fields with expressions, add filters via expressions, etc. QGIS helps to configure layers options, not only symbology.

Please do not drop features too fast. Many users rely on them now.

elpaso commented 7 years ago

@ocourtin I agree that Auth is out of scope for the QGIS Server tier, but I'd like to keep all the main OGC services available, what I was thinking of is a C++ plugin-based architecture in which every service is a independent plugin, this would make the transition much smoother:

pcav commented 7 years ago

+1 for keeping at least WFS. As for dropping features, we must be careful: if QGIS3 will not have an usable server, people will be forced to stick to QGIS2, or to keep both version, thus resulting in an effective forking of the project, or at least of the community, a Bad Thing that caused huge problems in several important OS projects.

rldhont commented 7 years ago

@m-kuhn @nyalldawson what can we do to fix the QGIS Server tests ? https://github.com/qgis/QGIS/pull/3510 What can we have to do to have Qt5 and Python3 well support in QGIS Server ?

NathanW2 commented 7 years ago

Why not spit QGIS Server off as it's own project and repo? Does it make sense to keep in with the desktop source?

On Fri, Sep 23, 2016 at 9:53 PM, rldhont notifications@github.com wrote:

@m-kuhn https://github.com/m-kuhn @nyalldawson https://github.com/nyalldawson what can we do to fix the QGIS Server tests ? qgis/QGIS#3510 https://github.com/qgis/QGIS/pull/3510 What can we have to do to have Qt5 and Python3 well support in QGIS Server ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/qgis/qgis3.0_api/issues/63#issuecomment-249172493, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXS3GAqDxjL1YRbpd0MEP_QjZodh_G-ks5qs73VgaJpZM4KDndY .

elpaso commented 7 years ago

@NathanW2 I think it does, as long as they share the same project files they need to be in sync. IMHO the unique selling point of QGIS Server is that you create a project on the desktop and publish it on the server and see the same rendering on both.

NathanW2 commented 7 years ago

Yeah not saying that just from a code point of view putting it outside and managing as a standalone project. I don't use it so I have no input on it's direction into the future.

On Fri, Sep 23, 2016 at 10:17 PM, Alessandro Pasotti < notifications@github.com> wrote:

@NathanW2 https://github.com/NathanW2 I think it does, as long as they share the same project files the need to be in sync. IMHO the unique selling point of QGIS Server is that you create a project on the desktop and publish it on the server and see the same rendering on both.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/qgis/qgis3.0_api/issues/63#issuecomment-249176774, or mute the thread https://github.com/notifications/unsubscribe-auth/AAXS3EqvVaLRd2I_FvPR5qZdK3glkcXpks5qs8NTgaJpZM4KDndY .

ocourtin commented 7 years ago

@elpaso @mdouchin @pcav

WFS implementation (i mean an interoperable one) is something big to achieve (and then to maintain).

It would be that cheaper for QGIS project to just provide kind of binding allowing from a .qgs other already existing WFS server to deal with.

On this way you don't loose feature for the end user. In fact you just provide more and better...

strk commented 7 years ago

On Fri, Sep 23, 2016 at 05:17:23AM -0700, Alessandro Pasotti wrote:

@NathanW2 I think it does, as long as they share the same project files the need to be in sync. IMHO the unique selling point of QGIS Server is that you create a project on the desktop and publish it on the server and see the same rendering on both.

This reminds me of another discussion about having a formal specification for the project files.

timlinux commented 7 years ago

Can I suggest we close this issue - I think if we table ideas like this it would be better to do it in a more constructive way. A lot of people use QGIS Server and I do not think we would serve them well by simply removing the code for QGIS server from the code base. Thanks!

m-kuhn commented 7 years ago

Happy to close it. I has triggered a very constructive discussion. Long live QGIS server :+1: