On Fri, Oct 28, 2011 at 5:12 PM, Justin Deoliveira <[email protected]> wrote:
>> - security: some processes might be available only to specific users
>> (no implementation planned along this lines, but this will make it
>> possible)
>>
> I wonder if it would make sense to add processes as another catalog
> resource, allowing the admin or whomever to manage them like other resources
> in the catalog. It would also fit nicely into the current catalog security
> model.
Hum... ProcessInfo. Sound like quite a bit more work to get the same result
(catalog and persistence work, and synching between config and the pluggable
list of processes available).
What would ProcessInfo cointain besides a name?
And what if a new process is plugged in, how does relate to a ProcessInfo
(that we still don't have since the configuration moves in an unrelated way
compared to the process plugin system).
Seem kind of like trying to stick in the catalog the stores types,
coverage types,
output formats and the like (any pluggable subsystem in general).
I guess it could be useful if we need to roll some static config parameter
in the process.
The filtering use case I actually need to address won't use at all the standard
configuration, but a custom plugin for integration in a larger enterprise
enviroment, same goes for security, it won't be based on the normal
GeoServer one.
I was trying to include the first to give the community something useful
besides just the machinery :-p
>> The callbacks could do a number of services, for example:
>> - security, disallowing certain combinations of processes and inputs
>> (e.g., one might want to disallow downloading data from remote hosts)
>> - accounting, register who made what wps call, for how long, with how
>> much data
>
> I like it. The idea of ows service specific callbacks is one I have thought
> of before as well. Might be nice to lay down a general pattern for such
> callbacks... perhaps giving callback methods for each service operation, and
> then some additional ones specific to a operation. Just thinking out loud.
Here is what I was thinking for WPS:
ProcessCallback {
void beforeInputParsing(ExecuteType) throws ServiceException;
void beforeExecute(Name processName, Map<String, Object> inputs)
throws ServiceException;
void beforeEncoding(Name processName, Map<String, Object> inputs,
Map<String, Output> outputs) throws ServiceException;
void complete(Name processName);
}
The above is pretty specific. What I'm wondering is, what generic methods can we
provide that are talking about the operations, but that are not already covered
by implementing DispatcherCallback?
Like, say you want to make a callback for WFS GetFeature... how would
it look like?
I guess it could advertise details about the transformation between
the wfs queries and the geotools
queries.
Or, what about a GetMap one? For this one I'm clueless, as each map encoder does
things differently (e.g., we might not be even calling into
StreamingRenderer for example).
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
