Hi,
The dark side is that there still exists some other implementations than
Geoserver, and people who have learned to use, let’s say, WFS without
&SERVICE=WFS, are making questions about why other server brands require such
obviously unnecessary parameter. We do also complain about QGIS being too
flexible with SLD etc. So I think there should be some balance between doing it
“right” and to have a continuous support for historical decisions to allow
doing it “wrong” even it is difficult.
-Jukka Rahkonen-
Jonathan Moules wrote:
Re: [Geoserver-devel] On breaking backwards compatibility
Hi Andrea,
Excellent points - I've seen such deployments first hand.
A prime example of backwards incompatibility between versions is the jump from
Python 2 to 3. Python 3 isn't entirely backwards compatible with 2 (refactoring
is often required), so uptake of 3 has been considerably slower than for a
minor version update.
That said, assuming GeoServer ever makes the leap to 3.x, it may be worth
considering implementing sufficiently important backwards-incompatible changes
then, like the Python folks did for Python 3.
Just my 2p,
Cheers,
Jonathan
---- On Fri, 17 Mar 2017 07:48:41 +0000 Andrea
Aime<[email protected]<mailto:[email protected]>> wrote
----
Hi,
seeing proposals that do break backwards compatibility, I believe it's time to
make it clearer as to why backwards
compatibility in GeoServer is very important (and breaking it represents a
fatal mistake most of the time).
The common GeoServer deployment in public administrations is one or more
GeoServer installations
being accessed by a variety of internal and external clients. The range of
clients accessing the server
is vast and often completely out of control of the admins... because this is
the nature of an interoperable
service, it does not talk with a specific client, it's make to talk with
everybody.
To give a small summary:
* Internal users using one of the task specific web applications
* Internal users with desktop clients (often different types, different
departments might have different desktop clients, sometimes different versions
of them, especially if the desktop client in question does not require a
licence and the power user in question got the right to install programs
locally)
* Other internal services cascading or consuming the OGC service (SOA like)
* External users, same as above but with a lot more variability
The admins every now and then need to upgrade the server, be it because of
security reasons, a critical bug fix, or because a new application requires
extra functionality provided by a newer version.
When they do so, they need to ensure that everything else keeps on working...
and that's a lot of pain, because most of the clients above are _outside_ of
their control, even the in house ones:
* Maybe a web application provided by a external vendor relies on some
extra flexibilty (e.g., not requiring the version or service), upgrading it
breaks it, but to fix the application a new contract with the provider needs to
be setup (administrative and econominal issues arise)
* Maybe an internal desktop client is in the same boat, but an upgrade of
the client might require contracts, or verification that plugin X custom
developed still works on the newer version, and so on.
Long story short, doing upgrades requires a lot of verification, and the
slightest backwards incompatibility just breaks havoc and makes the upgrade
impossible (which, in case of upgrades related to security fixes, makes the
situation untenable).
That's why I keep on using a hard line on backwards incompatible changes, even
when fixing a mistake: being "right" is not enough, operational continuity is
more important than that.
That does not mean we cannot change stuff, but at least a fallback option to
re-enable the previous behavior must be always provided.
Cheers
Andrea
PS: there is also a good read here
https://en.wikipedia.org/wiki/Robustness_principle
To it, I'd add that on day one it's good to be as strict as possible, but once
the deploys happen, whatever
flexibility remained should be kept.
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i
file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo
è consentito esclusivamente al destinatario del messaggio, per le finalità
indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne
il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di
procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro
sistema. Conservare il messaggio stesso, divulgarlo anche in parte,
distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse,
costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the
attention and use of the named addressee(s) and may be confidential or
proprietary in nature or covered by the provisions of privacy act (Legislative
Decree June, 30 2003, no.196 - Italy's New Data Protection Code).Any use not in
accord with its purpose, any disclosure, reproduction, copying, distribution,
or either dissemination, either whole or partial, is strictly forbidden except
previous formal approval of the named addressee(s). If you are not the intended
recipient, please contact immediately the sender by telephone, fax or e-mail
and delete the information in this message that has been received in error. The
sender does not give any warranty or accept liability as the content, accuracy
or completeness of sent messages and accepts no responsibility for changes
made after they were sent or for other risks which arise as a result of e-mail
transmission, viruses, etc.
-------------------------------------------------------
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org!
http://sdm.link/slashdot_______________________________________________
Geoserver-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
