> Moving on to something WPS specific, we need to be able to declare
> what mime types the input files/streams
> we are going to accept, and which ones we are going to produce.
> Normally we avoid this issue in GeoServer by trading objects (e.g.,
> RenderedImage, Coverage, FeatureCollection)
> that specialized utility classes (ProcessParameterIO) turn into a
> serialized format with a specific mime type.
>
>
Yep; and I got stuck reverse engineering PPIO for the WPS client codebase. So
any assistance on mime types would
be very welcome.
> But there are processes around that really do trade files, and
> specific formats of them for what is worth.
>
>
Agreed; the client implementation needs to know as well.
> For files that are inputs we could have something like:
>
> @DescribeBinaryInput(..., mimeTypes = new String[] {image/png,
> image/jpeg, ...} ...)
>
> The mimeType would have then to be carried around by Parameter, which
> has a metadata map
> that we cannot read... can we add a getMetadata(key) method in there
> to access some random
> metadata?
>
>
That was going to be my suggestion - Parameter already has the following.
/**
* File extension expected - "shp", "jpg", etc...
*/
public static final String EXT = "ext";
So a mimeType would not be out of place.
> Dealing with the output formats instead is going to be loads of fun.
> We can have a
> @DescribeBinaryResult( ... mimeTypes = new String[] {image/png,
> image/jpeg, ...}
> and that would allow us to run DescribeProcess, but when it comes to
> executing the fun starts,
> since the user will choose one of the output formats as part of the
> _output_, not as part of
> the input:
>
> <wps:RawDataOutput mimeType="image/png">
> <ows:Identifier>theImage</ows:Identifier>
> </wps:RawDataOutput>
> </wps:ResponseForm>
>
> How is the process going to know that the user requested image/png as
> the output format, since
> that's not part of the inputs?
> All I can think if being explicit about which of the input params is
> going to be mapped to such choice,
> and avoid exposing such param in the DescribeProcess:
>
> @DescribeBinaryResult( ... mapToInput = "outputFormat")
> @DescribeParameter(name="outputFormat") String outputFormat
>
> Any better idea?
First up - I like your idea.
However I may have a better one; for long running processes we have the case
where we would like to stick a process listener in as one of the parameters.
This is a similar issue - perhaps we can gang up on the solution.
public static double expand( double scale, @DescribeResult( …. )
ExecutationContext context){
String mimeType = context.getMimeType(); // mimeType selected by user
ProgressListener progress = context.getProgressListener(); // used to
track long running process, may be NullProgressListener
…
return 3;
}
While ProgressListener offers us a small amount of control; I think a full on
callback object (i.e. something like ExecutionContext ) would offer GeoServer
better control and interaction. At the very least it could hold the status
ticket so any log messages are more descriptive.
> 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)
Understood: perhaps we can handle this the other way around; only processes
which accept an ProgressListener (to report streaming progress) should be
considered to support streaming.
I assume we can return an error result in this case; indicating that async is
required. Does WPS 2.0 say anything on this topic?
> However I don't see a way to expose this from ProcessFactory, and it's
> indeed something
> that would be pretty WPS specific. Maybe we should augment the ProcessFactory
> to return a open ended metadata map about the process?
>
> Map<String, Object> getProcessMetadata(Name process)
See the following:
http://geekandpoke.typepad.com/geekandpoke/2012/06/how-to-create-a-stable-api.html
I would prefer a real object where we commit to the keys used over time. Using
the keys from Parameter, or something like how QueryCapabilities was done.
Andrea my uDig workload is settling down, I am interested in seeing this API
settled, let me know if we can collaborate on this one.
Jody------------------------------------------------------------------------------
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
