Martin Desruisseaux wrote:
> I'm using them in production (through MosaicImageWriter) before I
> suggested those classes last Monday...
So you understand how Executor is isolating the implementor of Callable
from external influence; in order to have more flexibility and control
over what is going on. The trade off and motivations for their strict
design decisions are clear to you ... do you actually agree with them?
> However I do not yet understand why the proposed interface could not
> spread the tasks across servers, and I wasn't seeing a cancel() method
> as a huge responsability (no need to synchronize; declaring the field
> as "volatile" is enough. Even if the developer fails to put a
> "volatile" keyword nothing will broke. The only consequence is that
> the process may take longer to stop).
I am seeing the addListeners as a huge responsibility (too heavy to hold
up by anyone, without limiting the Executor beyond usefulness). Cancel
is not such a problem, but I am not sure I see the same use case as you
... basically I don't want the user to hold on to the process Object
after it has been dispatched, I believe that to do so would be a design
mistake on our part.
Can I ask if in your experience you are holding on to your Callables
after passing them to an Executor?
> Anyway. The reponsability aspect could be adressed by defining an
> abstract class rather than an interface:
> public abstract class Process<E> implements Callable<E> {
> public void cancel() {
> // To be implemented ourself.
> }
> public void addProgressListener(...) {
> // To be implemented ourself.
> }
> protected void fireProgress(float percent) {
> // A convenience method to be invoked by implementors.
> }
> }
Indeed; we are already defining several abstract super classes to meet
the existing Process interface contract. It is my hope that if we use
them in all the examples users will not be tempted to mess up the API
contact. But the example provided by Executor/Callable is strong, and
even more careful that what we have outlined thus far.
> I had a look at the proposed "process" module and I see Process,
> ProcessFactory, ProcessFactoryFinder, Parameter classes which seem a
> parallel architecture to Callable, Executor, ISO 19111 Parameter, etc.
> The proposed classes give me the feeling that Process needs to be
> obtained (and maybe executed - not sure) from a ProcessFactory which
> needs to be declared as services in META-INF/services/.
Only obtained; ProcessFactory is not needed to Execute.
> I can see a need for that from a GUI point of view, but can we split
> in two parts?
Yes we can.
>
> 1) A Process class implementing Callable. This class should be usable
> directly
> in java.util.concurrent by the user as he see fit, with only
> additional
> fonctionality for reporting progress and canceling. Users should be
> able to
> run this Process with the Executor of his choice.
Is it enough if I provided an adaptor to convert a Process into a
Callable (so the user can use it on the Executor of their choice)? I am
very fond of the Executor / Callable design now that you have had me
look it over, I find it stronger then my original suggestion.
> 2) A ProcessFactory which may be used (but not required) for creating
> process through:
> Process create(String name, Collection<Parameter> parameters);
One final point of query here (something we struggled with last week),
should the input parameters be only visible as part of
ProcessFactory.create, or should they be part of the Process interface
itself in the form of a setInput method, or explicit "execute( input )"
method.
Jody
-------------------------------------------------------------------------
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
