On Mon, Aug 13, 2012 at 11:18 PM, Andrea Aime <andrea.aime@anonymised.com> wrote:
On Mon, Aug 13, 2012 at 11:45 PM, Martin Davis <mdavis@anonymised.com> wrote:
The wildcarding should make this easy. The default configuration would have “*” in the whitelist, and nothing in the blacklist. This makes all new processes visible by default.
If a more restrictive whitelist was in place, and new processes were being added in a given namespace “ns”, then the admin simply has to add “ns:*” to the whitelist.
I don’t see anything simple in having to remember by heart prefixes and process names, in particular
I find very obnoxious the “limited srs lilst” thing in wms page exactly because it forces one to have
to remember by heart the list of EPSG codes one wants to activate.
I guess some have a much better memory than me, but if the only UI available would be the one you
say in order to fill that box I’d have to grab the WPS capabilities document and start copying and pasting
the names of the processes I want (out of a XML document, ugh), doing it by heart I’d be sure to
introduce typos and other little errors in the list.
Well, there’s the RequestBuilder drop-down, and we’re working on a Process List page. So there’s a few places to find process names. And presumably this is a fairly infrequent activity, and there won’t be 1000’s of processes. Also, the wildcards allow easily referring to groups of processes.
Regarding the while versus black list, the UI I’ve made is very explicit, you see all processes and you
can check on and off the ones you prefer, what makes it a blacklist is the behavior against unknown
processes, if a new process is not in the list it’s allowed to be exposed.
If having a whitelist approach is deemed to be important we can have a checkbox on top of the
groups table stating “Automatically enable new processes” that the admin can check on and off,
and saving in WPSInfo not only the list of the processes that are to be filtered out, but also the
one of the enabled processes, and the checkbox will deal wiith the rest.
I don’t have a strong feeling about having a whitelist as well - it was a just a potential extension which would be fairly easy to add.
I guess I don’t have a clear picture for what your use case for this functionality. I can imagine a couple of different uses:
a) Expose only a few “safe” processes (say some custom ones developed by a organization, or say all the geometry ones). In this case a whitelist would be easier.
b) Remove a few “unwanted” processes (due to failures, or to avoid overuse of resources). A blacklist would work better for this.
Let’s put it like this: we have a -1 from me on such a UI, and a +1 from you of course.
Let’s hear from others, if textbox approach gets a majority feel free to implement it and scrap mine 
Would be interesting to hear input from other GeoServer devs and admins. Or maybe just implement it and get the feedback later. 8^)
The latter would be rather hideous, a developer overwriting another active developer work just based on his
personal judgement.
That’s not how we work around here, we try to reach consensus instead, even if sometimes it is a painful
one to reach.
I just meant that you’ve already committed your work to trunk, so the default path is to leave it in place, and perhaps to hear real-use feedback from other devs and users. It sounds like you have a pressing need for this functionality, and I don’t know how much time we have available to develop a different approach.
As said, let’s have others take a position as well if they think one solution is better than the other, if
we don’t get any development I’d suggest to keep the implementation we already have.
Cheers
Andrea
–
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 962313
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
–
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
