Save the history for a subpage; limit the proposal page to what you want to see done (same advice I gave Gabriel).
The actual content seems fine, review gabriel's submission for admiting that getReader and getWriter exist (it is listed as a design goal). The fine details: - create a jira to track this one - don't bother with getFeatureWriterUpdate( Query ) it is only filter is needed - I like getWriterInset() - I had written down getWriter( append ) with the understanding it would handle the Filter.INCLUDES and insert case - can I have my visitor method ;-) Suggestions: - can we have a seperate interface for inserting content; this dual purpose FeatureWriter is a waste of time, space, and complexity. Thinking of FeatureWriter and FeatureInsert here Useless history: - the reason I have stuck by FeatureCollection here is I want to make sure our low level api (FeatureReader, FeatureWriter etc...) can support high level constructs of *some* kind; as we will need this to implement associations in a lazy manner over on the Feature/FeatureType side of the fence. Cheers, and nice proposal. Jody > I have been giving a bit of rough feedback to others for their proposals > so here is a chance for people to get back at me. I finally got around > to writing up my ideas on how to cleanup data access with regard to > feature collection. > > http://docs.codehaus.org/display/GEOTOOLS/DataStore+Cleanup > > -Justin > > ------------------------------------------------------------------------- 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
