Hi Justin Thanks for your input. The link to the existing API is, that at a later stage DataStore should extend DataAccess, FeatureSource should extend Source, etc. If you want to see an example of an implementation of the new interfaces have a look at unsupported/jpox. I agree with you that we kind of dumped the new interfaces on all of you, but Jody thought that's the only way to get everyones attention... ;)
I don't agree at all about uDig...it certainly wasn't solely on our mind, when we designed all this. I'm seeing that there's a great deal of tension between uDig-devs and other GeoTools users (GeoServer-devs?) about the catalog stuff. Can't really comment on that, because I don't know to much about it, but as I see it, we only use one catalog interface at one one point in those new interfaces and that use seems to be very justified to me. Bye, Thomas Justin Deoliveira schrieb: > Hi guys, > > I am looking over these interfaces and they seem to be an abstraction of > the datastore api. This is kind of out of left field if you ask me, > perhaps i missed discussion on the list about this. > > I see links to the catalog api, but none to the datastore api. Is there > a link? I realize there is a need to be a bit more abstract to handle > things like coverages, but an entirely new api? > > Hate to say it guys, but this smells oddly like udig just dumping > interfaces into geotools. With a lack of documentation as it is I hardly > think that we need three new interfaces in a core module like api. > > -Justin > ------------------------------------------------------------------------- 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
