Based on the 29 open tickets which deal with non-simple resource names we have
real issues with them. Could we at least try to emphasize in the documentation
and perhaps with some warning in the GUI that using such names calls for
troubles?
-Jukka Rahkonen-
________________________________
Jody Garnett wrote:
I am uncomfortable with the idea of silently disabling feature type layers - if
the user has turned on both WFS and WMS publication.
This proposal has drifted too far from my original goals. I will mark it
withdrawn and focus on fixing the style names in isolation.
--
Jody Garnett
On 30 January 2015 at 13:33, Jody Garnett
<[email protected]<mailto:[email protected]>> wrote:
So we are left with the question of how to notify admins for layers that are
disabled for a specific service.
As for the styles name change (damage is currently already done and is
affecting ability to upgrade) we can either allow the invalid characters (with
a warning) or watch them fail.
--
Jody
--
Jody Garnett
On 30 January 2015 at 13:05, Andrea Aime
<[email protected]<mailto:[email protected]>> wrote:
On Fri, Jan 30, 2015 at 7:29 PM, Jody Garnett
<[email protected]<mailto:[email protected]>> wrote:
I guess I see where the friction is coming from, you are focused on the
external name used by WMS and I am thinking of keeping our internal catalog
consistent. Usually we have kept the name as internal machine readable for
machine to machine communication, keeping the title and description for humans.
Let me break it to you: title and description are, in the field, pretty much
irrelevant, what counts is the name you publish in the services,
the one the clients will use to make the requests.
In my experience title and description are used by the clients that are
following the full protocol in order to discover the layers
and present a description to the user, that is, desktop clients, and those web
clients that allow you to dynamically mix in
layers from remote, provided at runtime, servers.
To those clients changing the layer name is irrelevant, because they are
discovering it every time, but they represent a very
small part of the actual traffic.
In most (all?) the small and big traffic sites I've seen the main traffic
driver is the custom web/mobile application that you setup
in order to expose whatever business service you are providing (rounting? green
areas management? wheather forecast?)
That thing knows the layer _names_, not titles and description, if you change
them while upgrading GeoServer the few
important web clients out there are broken, and you're not really providing
services anymore (that is, 99% of your traffic
is instantly gone).
I was just talking yesterday to some customers, their main concern was "can't I
just upgrade the GeoServer to a new version?".
My answer has been that we try to do our best to preserve backwards
compatibility... a change in the name of objects
that are exposed to the clients is exactly the opposite, marches straight in
the direction of maximum damage
To give you another small example, we have a customer that had published sample
URLs that did not have the &version
parameter, when they upgraded GeoServer some time ago, and WFS passed by
default from 1.1 to 2.0 we had a very bad week
with their customers complaining like crazy that the responses changed.
Eventually I've implememented a servlet
filter that forces 1.1 in case it's not specified... (yes, adding a
configuration to GeoServer to choose the default
version would have been better, but we were in damage control mode).
Long story short, an upgrade should always be transparent.
If you are that worried about the layer name is it worth breaking out a layer
field specifically to take control over what is seen on the WMS protocol? Yes
by extension you could have specific fields for WCS and WFS but I am not sure
those protocols are as sensitive to web map client restrictions?
They are used a lot do perform small extraction/download, we should not break
names there either.
As said above, an automatic name change during a installation upgrade is simply
a no-go, it's irresponsible and
will cost us a lot of users if we go that way.
I still go back to my previous idea, if a name is unsuitable for the a
particular protocol/version name restrictions, just
hide it to avoid breaking the protocol, but leave if for the protocols/versions
that do not mind.
It's easy, eliminate the damage of ill chosen names, and put the admin in a
position to amend whatever does
not otherwise damage them
Cheers
Andrea
--
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/NWWaa2 for more information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313<tel:%2B39%200584%20962313>
fax: +39 0584 1660272<tel:%2B39%200584%201660272>
mob: +39 339 8844549<tel:%2B39%20%C2%A0339%208844549>
http://www.geo-solutions.it<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.
-------------------------------------------------------
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
