On Sat, Jun 9, 2012 at 1:00 AM, Andrea Aime <andrea.a...@geo-solutions.it>wrote:
> On Sat, Jun 9, 2012 at 9:21 AM, Martin Davis <mda...@opengeo.org> wrote:
> > 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...
>
> Yep, I agree. asynch=false would make sense for a WPS server that gives
> the process writer the onus to handle an asynch process, but GeoServer
> makes that transparent.
>
> One borderline case would be a process that has no support for progress
> notification, yet can take long and is not streaming.
> I'd argue such process is likely broken, but implementors might argue back
> that adding progress support is too much of a overhead.
>
Actually this kind of thing is not too uncommon in geometric algorithms.
There are algorithms for which it is hard or inefficient to determine the
progress (eg. as a percentage), but which take a long time and cannot
easily be streamed. Sometimes there are alternatives which can be
streamed, but the implementation is either unknown or a research problem.
A classic example is Delaunay Triangulation over input of unknown size (eg
streamed). Buffer is another example.
But surely these still be called as asynch, but with no feedback on
intermediate progress? And with no ability to stream the output it would
be *better* to make the call asynch (for the reason mentioned of unreliable
network).
Anyway, no matter, the ability to say asynch=false should still be
provided, since the spec needs it.
> > 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.
>
> That's the key, knowing in advance. In the rest of GeoTools we did not
> assume
> we could know in advance, and indeed new needs have been popping up
> over time.
> One could say that a class can get new fields, and I would agree, but it
> you
> have a need that the community does not share you're forced into a fork,
> a map is more lenient in that direction.
> I'd prefer an open ended map with well known keys for the reasons above
>
> Fair enough. I suppose as long as the keys are named constants it's still
possible to find where they are set and read.
Was there ever any thought about using named subclasses of HashMap to make
usage context clear?
--
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/
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
