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
