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]> 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]>
> wrote:
>
>> On Fri, Jan 30, 2015 at 7:29 PM, Jody Garnett <[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
>> 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.
>>
>> -------------------------------------------------------
>>
>
>
------------------------------------------------------------------------------
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
