I like Juan's goal of reducing the number of logical combinations that have
to be considered.  It seems like the WPS spec has it backwards.  What you
really want to know is whether a process can be called as synch - *any*
process could be called as asynch, with the only repercussion some slight
inefficiency for fast processes.

So maybe provide both synch and asynch annotation attributes, but default
them both to true, so that the only thing that really needs to be supplied
is synch=false for long-running processes?  I'm not sure when you would
ever want to say asynch=false...

As for providing this metadata in a Map, is a more structured alternative
to provide a specific class carrying the various metadata values?  I guess
Maps are used elsewhere in GT/GS for this kind of thing, but in this case
where the parameters are all known in advance it seems like a type-checked
class would give more support.



On Fri, Jun 8, 2012 at 5:03 AM, Andrea Aime <andrea.a...@geo-solutions.it>wrote:

> On Fri, Jun 8, 2012 at 1:40 PM, Juan Marín Otero
> <juan.marin.ot...@gmail.com> wrote:
> >> One final thing that happened to me while writing processes is
> >> realizing that  a process
> >> will take long, that it cannot be written in a streaming manner for
> >> some reason, and thus
> >> really wanting the process to be only run in asynch mode.
> >> Ideally it would be nice to have the following:
> >>
> >> @DescribeProcess(... synch=false, asynch=true)
>
> If a process runs fast
>
> >
> > I really like this idea, and had been wondering about it. I'm not sure if
> > you want synch and asynch, perhaps only keep asynch with a default value
> of
> > false?
>
> Hmm... this matches what the WPS protocol exposes, there is no way to
> say a process cannot be run in a synchronous way, one can only say
> that asynch is supported or not.
>
> Yet, the GeoServer WPS is transparently supporting asynch, so it comes at
> no extra cost for the implementor, and little extra cost for the server.
>
> What I really want is a way to deny synchronous execution of processes that
> take so long it's unreasonable to think a HTTP call can be kept up that
> long.
>
> Long story short, I believe asynch = true and synch = true is a better fit
> for
> the general case, and even if we cannot advertise it, I'd like to have the
> option to throw an exception if a process is called in synch mode when
> it has synch = false


-- 
Martin Davis
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to