Thanks Andrea for the email documenting what you will accept. I am not sure exactly what I will accept yet - but will think on it for later.
Andrea Aime wrote: >>> Andrea GeoServer (and generating GML) is not my only concern here; I >>> would like to open the door to rich content beyond our feature >>> model. Since we have failed to produce one (and something like EMF >>> seems to be taking over) it seems best to sit on the sidelines. >> >> If we cannot "reflect", "inspect" at least the simple properties out >> of that Source thing, then I'm against having it around. >> It just adds confusion and provides little value imho. >> Of course it's a matter that the PMC should discuss, so if mine it's >> the only -1 with two vote sessions you can get away anyways. > Oh, to be more clear, what I'm really concerned about is to have two > separated paths in the code for handling Source and FeatureSource, > this is what I find totally unacceptable. Got it - let me layout the targets then.... So if we rephrase that: Option 1: FeatureSource extends Source - single code path - check - does it set up for FM - unknown - does it handle GC - unknown - does it handle Metadata - unknown - does it handle Pojo - yes - does it handle Metadata - unknown - does it handle EClass - yes (same approach as pojo) - does it handle Schema Option 2: Fix gaps in FeatureSource* - single code path - check - does it set up for FM - by definition of "fix" - does it handle GC - only if GC and Feature model issues are worked out - does it handle Metadata - no (not DeeGree forces Metadata to extend Feature in order to cover this base) - does it handle Pojo - no (but could with complicated reflection, andrea do you have your hibernate datastore code?) - does it handle EClass - no (see above) - does it handle Schema - maybe (see Justin's work) Basically Option 2 involves a lot of up front code to bridge the gap between models, doing this a) is not always possible as in the Metadata case b) places a large implementation burden on using our library with other content. Option one lets people write a minimal class that let's our rendering system access content according to already provided expressions (presumably by those who hooked up the data). It target audience here is programmers who want to reuse our codebase for our high value propositions (rendering and reprojection). So this is a strategic step that acts in concert with setting up the library for the new feature model. In a sense it is *too* successful as it would enable us run large portions of the library with two feature models (and nobody is interested in seeing the duplication of effort this would cause). > As for having the interfaces around with no duplicate code paths, > I'm not totally against, I still think they do add to the confusion > without provide any value, but at least they do not harm too much. We can set up FeatureSource to extend Source and arrive at a single code path (yeah), but right now the rendering code contains a lot of hacks to work around problem datastores (ie maybe the datastore coughed up a geometry in a projection different from what was requested? right now the renderer detects this and works around the problem with wrappers!). So my best case scenario is to Option 1, finding the DataStores that do not work (ie they "lie" to the rendering system) and giving them good bug reports. Jody PS. Andrea there are two more shoes ready to drop a) Justin & Jesse w/ catalog compromises b) transaction and the relationship with locking and Identifiers (note "Identifiers" not "fid" captured as classes rather then String as per OWS4 work). ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
