Martin Desruisseaux wrote:
> So I assume that the interfaces would looks like that:
>
> public interface Process {
> void process(ProgressListener listener);
>
> // Some input and output methods for parameters
> }
>
>
> Would it be appropriate to rename the other interfaces in a way that
> remind the Executor / Future in java concurrency, so that someone
> familiar with them can naturally make the parallel with the process
> interface? For example:
>
> public interface ProcessExecutor {
> ProcessFuture submit(Process);
> }
>
> public interface ProcessFuture extends Future {
> void cancel();
> }
>
> (implementation of ProcessFuture could delegates most of its methods
> to a java.util.concurrent.Future that it is wrapping)
Good call; all around ... I will talk to Graham.
> One last question: I noticed that you define a new Parameter interface
> instead of using the one that was defined in ISO 19111.
This was initially done for two reasons:
- familiar to GeoTools programmers - copying the working example
provided by DataStore Param / DataStoreFinder
- the alternative of using a Java beans and after a discussion of the
problems faced with this practice in the GeoServer project
(internationalization mostly)
We looked again at the using Java beans simply because it would make
producing a desktop user interface a lot easier. Turns out they simply
don't meet the our needs for WPS work- specifically:
- Java Beans Descriptors cannot communicate the multiplicity constraints
- Java Beans have no ability to work against our "dynamic type systems"
like FeatureType
Finally the nature of how Java BeanInfo objects are collected means we
cannot simply extend their work; the bean introspector does a
complicated reflection/caching routine and our descriptor instances are
thrown out after they have provided the introspector has collected the
information out of them.
> I remember that you tell us that the ISO one was not useable in
> graphical user interfaces, but I have not understood why... You have
> been very patient explaining me why you wanted cancel() out of
> Callable. Is there any chance that you can use again some of your
> great patience for explaining me why ISO 19111 is not suitable, and if
> there is any thing we could do for fixing it?
I would need to revisit our email thread of some years ago ... here is
what I recall (it has been a while so please be kind if I get the
details wrong)
- it took us a long time to sort out ParameterGroup and the restrictions
is describes are not a natural fit to Java classes the same way Beans
ae. I remember issues such as order, group serving two purposes (used to
handle multiplicity/Arrays and to handle compound types/Structs )
- I liked the one Bryce mentioned a lot more at the time (the one
referenced WRS at the time, now known as ISO19119) - that specification
has all the same ideas but presents them in a way compatible with
FeatureType and RecordType etc...
For the GeoAPI project I would much rather see ISO19119 explored as a
long term solution to Services/Parameters etc...
Now we do have another alternative; that I have not explored; but is
related to your request (ie reuse a geoapi interface rather than make up
something). The FeatureType model includes OperationType and
OperationDescriptor and so on ... this is similar (and perhaps
identical) to what we need.
My feelings on the matter? Let's learn what is needed by watching this
project happen ...
- Fix up the GeoTools Parameter class, see if we can reduce it to a
single Parameter class (work needs to be done anyway since groldan
copied it out for his DataAccess proposal)
- Watch the Parameter class evolve as it is used to provide information
to WPS, Eclipse and Swing.
- Explore the use of ISO19119 in GeoAPI and migrate both
DataStoreFactory and ProcessFactory to advertising their "services"
using a GeoAPI interface when it is ready
I admit that is a long term play, we could also *just use* the
OperationType / OperationDescriptor information from the feature model
if you feel a geotools Parameter should be avoided at all costs.
> I will be away until Wensday, so no rush I will not be able to read
> and answer anyway...
I will be moving house on Wednesday, so this will need to wait until
Thursday. I am really sure that I have used up all the patience the wps
team has on this topic (with good results I admit). Fixing up parameter
use for the GeoTools library as a whole will need to stay out of scope.
Jody
>
> Regards,
>
> Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
