Hi, and here is my feedback. As I see, you want to provide data in its native format, assuming that you can build appropriate property accessors in order to play with whatever is returned.
The touted benefits of this are, apparently, that it makes it easier to link whatever data you have already in your application, and that you can write code that mix-ins gt2 parts and "native" parts. Its existance also implies that going the other way, that is, extending AbstractDataStore and building wrappers that implement the Feature interface is too hard. DataAccess ----------------- The interface does not say anything about being able to provide read only or read write accessors. I see that there's a Store interface that extends Source, but it's completely empty. Describing type by returning the "native" type as in Object describe() is useless in my opinion, because it makes it impossible to write generic reading code. Something using this simply cannot be added to Geoserver, and it's a shame, because it would be nice to be able and serve pojo out of it, no? What I'm thinking is, if you can provide property accessors to your "content", then you can also sum up all the conceivable property accessors for your type and make something that looks like a FeatureType out of it, no? Why, instead of simply returning a useless "Object", can't we return something that implements an interfaces that _looks like_ Feature type? Maybe something that can list all "simple" properties around, those that geotools is able to handle at the moment, and a default geometry. Or, as a second alternative, provide services that turn these object description into something that can be understood at the geotools api level without any external intervention? If I know what the properties are I can conceivably write a WFS DescribeFeatureType response, and a GetFeature too (more on this later thought), turning the value of this proposition into something that can be accepted in gt2 and provide value too. Source ------------------- Here we have three content methods: * content() should be removed in my opinion, it's just very little convenience instead of content(Filter.INCLUDE). * content(String query, String queryLanguage) This seems to open the door to Source specific query languages. Interesting, but how in the world I do ask something using a gt2 Query? Simple answer is, I can't, unless I go thru the hoops of encoding the Query in xml and then decoding it... a very long road for the most straightforward case. Can't we have a Query interface instead, even an empty one, that can be implemented in various ways? If jpox likes the string road, it can have a JPoxQuery implementation with a string inside. Moreover, I would ask to force every Source implementation to at least be able to properly process a gt2 Query, in order to guarantee a minimum level of generic functionality. * content(Filter), this one is nice, but it really scare me that we don't have the ability to at least slice properties away as in Query. I'd like to have at least content(String[] propertyPaths, Filter filter) Since this returns something which is a black box, property slicing could become a suggestion instead of an order, so if your datastore cannot slice its data (the pojo case) it won't. But at least, those that can will benefit greatly from not having to load all the unecessary properties. All in all I still prefer to have the datastore forced to be able and understand a gt2 Query, it's more rich, you can write more and better generic reading code against it. I keep on asking for this because one condition to accept these in geotools is that we don't need to write code that handles Source and FeatureSource by two parallel paths, I hope you agree this would turn into a maintenance nightmare. For describe(), the same critics as above. setTransaction(t) is a nice addition, since on databases this allow you to read whatever you've written in the same transaction (other transaction won't be able to due to transaction isolation). Road for transition ------------------------------------------- If the above requests are met, I'm not against keeping these interfaces in geotools. But we need to be able and avoid at all costs double paths in code, I would be against any solution that requires those. How to avoid double paths? Well, I see two ways: * have FeatureSource implement Source, DataStore implement DataAccess, and have the abstract classes we have around provide hooks. This would leave out in the water people that have implemented FeatureSource directly. Or, maybe, add methods to DataStore such as "asDataAccess()" to avoid public interface explosion. Just like IResolve, but with guarantees. * provide adaptation, that is, wrappers that given a FeatureSource do turn it into a Source, given a DataStore do turn it into a DataAccess. This should make fixing code relatively easy, too. A final requirement is that all developers feel these new interfaces do provide value to geotools. To us Geoserver/uDig as direct users I don't see any, but I like the fact that we would allow people to use both Geoserver and uDig as building blocks that can be added to existing applications seamlessly. This is something that has been requested in the past too, and the above seem to be a good way forward. Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
