Here is my feedback: * getInfo()
I guess this is a little off topic of this proposal and related to the last. But I was surprised when i saw it go through today. I remember having voiced feedback about those interfaces not being fine tuned enough. All those attributes: schema, publisher, title, etc... dont apply in the common case, they really only apply to WFS as far as i can see. What I want is to have a bare minimum. Like just uri. Everything else like the above can be thrown in a subclass. That way implementors can chose to implement additional metadata interfaces if they choose, and only a minimum in the normal case. Also some of the attributes (like icon), need to be rethought. An icon is something that a ui will want to set, not something provided by a datastore implementor. I also think ServiceInfo and GeoResourceINfo are bad names. They imply catalog, and as it says in the proposal "they are not catalog". I dont know why my vote says +0... i remember having serious reservations on this one. Perhaps it is because i disapeared over this last week. * FeatureAccess I dont know how I feel about a new interface. I think we may want to consider a different solution with generics. Not that I love generics but in this case they may better apply. I assume gabriel has thought about this route? I think the name of this class is pretty bad to. * FeatureStore Having FeatureStore extend ComplexFeatureStore seems odd to me. I know that this mirrors the feature model but... In the least we *need* to change the name of this to something without the word "Complex" in it. But again... the new interface bugs me, and is invasive. From what i can tell the main motivation is to be able to override methods which take a feature reader with methods which take a ComplexFeatureReader. I am not sure this is necessary, see next point. * ComplexFeatureReader/ComplexFeatureWriter Again, not to beat a dead horse... but i think these super interfaces are unnecessary and generics might be cleaner. I would even rather just have next() return an object and have client code cast, rather then break out a new interface. So to sum up, this proposal needs to consider the alternative way of doing this which is cleaner. Adding a bunch of super classes which are poorly named gets a -1 in my book. Perhaps its impossible to do with generics... but i think its worth consideration. -Justin Gabriel Roldán wrote: > Hi all, > > the proposal to extend the geotools data access interfaces to allow working > with GeoAPI Feature and FeatureType as a superset of the current API based on > SimpleFeature and SimpleFeatureType is ready for your evaluation. > > The URL is > <http://docs.codehaus.org/display/GEOTOOLS/FeatureAccess+super+class+for+DataStore> > > And feel free to raise any concern as comments in the jira tracker for it at > <http://jira.codehaus.org/browse/GEOT-1701> > > Best regards, > > Gabriel > > ------------------------------------------------------------------------- > 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 > > !DSPAM:4007,47a9db0026015332866982! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
