Thanks Paul, you hit on a key issues. I know I myself have fallen into the trap of focusing too much on code reuse, and not enough on maintainability. While I agree with the fact that there is too much attempt at reuse in our code, I would not want to throw out the concept of reuse entirely. I think done properly it could be effective.
In my opinion the problem really boils down to is no internal api structure for datastore developers. The external api is all we have. Which leads to subclassing and reimplementation to the extent we have seen it. Its one thing to subclass, its a completely different thing to subclass properly. For instance, if you look at the eclipse api, they explicitly let the application programmer know when they can subclass, and when they cannot. whether its by putting something in a package marked as "internal" or comments in the javadoc saying that "client code may subclass methods x,y, and z" this is something that geotools lacks. My 2c. -Justin Paul Ramsey wrote: > All, > > After thrashing about for a while on developing our FDO provider > templating off of the MySQL provider, and using the Generic RDBMS > interfaces we have decided to take a new tack. > > I am cc'ing this to Geotools, because deep in their designy hearts they > appear to still hold onto the same core belief, that databases are > similar enough that doing an abstract database layer between the > abstract datastore implementation and the specific database > implementation will save more work in shared functionality than it will > generate in specializations. > > Having now seen this pattern in two different projects, I do not think > it is so anymore. > > Our experience in PostGIS FDO has been that of either (a) having to > bring in specializations due to slightly different implementations than > the Generic writer expected and (b) inheriting some > lowest-common-denominator assumptions that we did not really want, > brought into Generic because of which specific databases got implemented > first (MySQL, ODBC). > > The experience in Geotools has been, instructively, quite similar. An > examination of the actual PostGIS Geotools implementation at this point > will find a good deal of sub-classing and re-implementation of > supposedly generic things back down inside the PostGIS datastore. This > is theoretically all well-and-good... reuse what you can, reimplement > what you must. But the long term effect is to make the entire structure > brittle... what do you do when you find a bug in the abstract database > level? Fix it, and you could break workarounds throughout the > implementations. Leave it, and... > > It seems like a far more efficient system would simply have one "well > structured, high quality" example on a "relatively standard" database, > and let new implementors do code re-use through simple copy-and-paste. > Then you could be assured that the implementations will converge on > quality over time, and that people mucking about in the superclass layer > cannot accidentally break implementations. > > All this to explain, that we are going to move from postgis support > being in fdordbms to it being a separate fdopostgis provider, in the > style of the King Oracle provider. > > We will be working in our own repository in the short term, because we > need to get started, but hope to have a slot in the FDO repository once > the reorganization is complete. > > Paul > -- Justin Deoliveira [EMAIL PROTECTED] The Open Planning Project http://topp.openplans.org ------------------------------------------------------------------------- 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
