[...]
>> Following the new process implementation link [1], I have some
>> comment, to which it would be great to have some back-comment.
>> - the fact that I have to extend a class instead of implementing an
>> interface is a bit strange to me
>
> You can change it over to an interface if you like.

Yeah, that would be a good starting point.

>> - the fact that i am forced to create a factory class and even pass it to my 
>> module constructor, also
>
> I think that was trying to not duplicate the description of input
> parameters? Can you see any other reason for the factory to be needed?
> I would prefer some kind of process info; that is avaialble from both
> the factory and the process itself.

The factory is ok for me, it usually helps a lot, but I don't see the
point of forcing people to have one.

>> the process api? With Sextante it went the way round, right? I guess
>> they didn't adapt to the process api.
>
> What does Sextante do to describe input parameters and produced results?

No idea about what and how sextante does.

>> Any comments are welcome, in the meanwhile I will look out to find if
>> the factory and process can be generated somehow from annotations.
>
> If we could annotate the parameters and results that would be perfect.

That has also to be taken with care.

I have quite some experience in migrating scientific models to
frameworks and interfaces by now. What I know for sure it that to be
maintainable, you have to take all the burden from the model writer,
i.e. possibly he should be able to do no work at all.

The OMS approach is to simply keep the model design but annotate the
input and output parameters and also the method to be executed. That
makes a model ok for linking for OMS, but doesn't change one thing in
the nodel itself (ideally speaking).

In my opinion the process api would be ok, if, to make my model
geotools processing compatible, I just had to implement the an
interface that asks me to implement the execute method:
public Map<String, Object> execute( Map<String, Object> input,
ProgressListener monitor )

It would then be easy for me to create a few lines of code that inside
the method execute my model.

The problem is that I will have no time at all to work on the geotools
side of this, mainly because I would have to study the process api.
But if it would be possible to change the AbstractProcess to an
interface I would be willing to implement that for all the JGrass
models that I am extracting to be a standalone library in order to be
used by the geotools community.
Not sure if you guys see it usefull, in the case a factory is not present.

Micheal (refering to your last email), could you help me on the
geotools side of life?

Thanks for the discussion, I really want to implement the modules to
be usefull under wps and whatever.

Cheers,
Andrea


>
> Jody
>

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to