[...] >> 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® 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