It would be nice if we could migrate current Feature to SimpleFeature,
but maybe the best alternative is to call the new model something that
reflects the point - GeneralFeature, FlexibleFeature,
CompleteFeature, FullFeature, GenericFeature, etc
I dont know enough to choose between the implementations, and its not
my vote, but have been impressed that the debate got so constructive
in spite of lack of instant agreement.
Is it possible to pursue migrating critical client code like WFS and
WMS against these and see at what point you are forced to make a hard
decision about the implementation?
Rob A
On Feb 10, 2008 12:20 AM, Adrian Custer <[EMAIL PROTECTED]> wrote:
> Okay, once again with feeling...
>
> The good news is that all three approaches seem reasonable; even, the
> nogenerics version is better than I thought it would be.
>
>
> The naming schemes are *crazy* but I assume that that's orthogonal to
> the question at hand of which strategy to adopt.
> We surely can come up with a systematic approach, grabbing new
> words if necessary ('Flat' vs. 'Structured', 'ISO' vs. 'Simple'
> or some such combination). 'FeatureData' versus 'DataStore' are
> painful! I am even starting to regret the Complex word since
> that was a simple way to extend and contrast the older with the
> new.
> Is the feeling that we could come up with a well structured naming
> scheme for the new work, leaving some trivial and deprecated classes
> using the old naming scheme to allow older code to live on?
>
>
> For nogenerics, the general notion for access is to start by getting an
> iterator on the registered factories. Have you thought about a refresh
> mechanism for the iterator if it is long lived? (e.g. users starts an
> op, realizes that the required source is not available, adds it, keeps
> going with the op => the new source needs to be added to the chain). The
> situation will arise so we need to be clear on how we expect user code
> to handle it. Perhaps this also extends beyond nogenerics...
>
>
> Finally, it looks like I don't understand enough to be of any use in
> making the decision. I gave it a shot but my brain has exploded.
>
> good luck,
>
> adrian
>
>
> -------------------------------------------------------------------------
> 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
>
-------------------------------------------------------------------------
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
