On Sat, Jun 9, 2012 at 4:30 AM, Jody Garnett <jody.garn...@gmail.com> wrote:
> Yep; and I got stuck reverse engineering PPIO for the WPS client codebase.
> So any assistance on mime types would
> be very welcome.
PPIO are needed if you want a well rounded wps client, but I don't
see how you need them in the process api?
And even in case of the WPS client, there is nothing to reverse engineer
that I know of, they could be used pretty much as is.
Can you clarify?
> 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.
We actually already do, if a process accepts a ProcessListener as a parameter
one is going to be sent down.
> 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.
Ugh, but it would break the api pretty solid with quite a bit of processes
out there already using it.
I'd prefer to have a separate ExecutionContext object that can contain
extra infos such as the output mime type, wheter the process was
called as synch/asynch, that would also address the need of not
running a process in a sunch way and would allow the process writer
more control, such as allowing synch run only under certain conditions.
The issue I see is that this ExecutionContext could have different contents
depending on the context. E.g., withing a WPS we'd like to have sync/asynch
and output mime type, within a desktop gui or a batch executor maybe
something else..
How about we roll two new annotations in GeoServer like this:
execute(... @ExecutionMode boolean synch, @OutputMime String outputMime)
Then GeoServer subclasses the annotation driven factory and also injects
those two if they are found?
Other enviroments might want to use separate annotations for processes that
are specifically geared to run withing a WPS... not sure we want to force down
everybody's throat functionality that is specific to running withing a
WPS service.
> @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.
Makes no sense, streaming processes never support progress listener as they
return right away and build the output as the feature
collection/raster is traversed.
> 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?
Where is the WPS 2.0 spec? I don't see it around.
>
> 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.
See my answer to Martin, it does not work when you need to use the
code for a custom usage that cannot be fed back to the official API,
forcing you into a fork
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
mob: +39 339 8844549
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
------------------------------------------------------------------------------
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
