On Wed, 2008-02-27 at 15:40 -0800, Jody Garnett wrote: > Jody Garnett wrote: > Please consider Eclesia's proposal to > be much more simple (and thus much > more likely to succeed).
Okay, then I have no comments really. If you are doing something tight that you understand, great. I thought I saw the beginnings of something else. > My goal here is to start java developer > creating "process" implementations; we can > wrap it up in something connected to a "registery" later... after all if > something takes a FeatureSource (ie the end > result of a reference) or a FeatureCollection (the end result of a > selection) why does the Process have to care > how these parameters were produced by the user? > > Just so we are on the same page Adrian: you see that the process results > in an Object? No I hadn't but it's nice. I tend to think of <result.set> which would have slots for you to put in process results, and other slots for commentary on the job and the whole thing could be totally or mostly empty for other processes. R has a nice habit of taking the return object and calling its .toString() method (more or less) so you see its output in the console. > Is the existing method > to determine the resulting Object type going to set up ETL style chains > of Process implementations? no idea about ETL. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
