Re: [Geotools-devel] DataAccess common ground

[Jody G. <jga...@re...>]

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).