Hi Jody, First thing i want to make clear is that this is not the proposal to make these things supported, just to restructure and continue to work on getting them to supported. Having them in a single "h2" module is not scaling and preventing us from effectively getting the real world resting we require. Additional responses inline.
Jody Garnett wrote: > The module restructuring is interesting; in general I like the layout of > "plugins" "library" etc... it lets people know what they are getting > into ... however I understand that build structure may be non optimal > product packaging. > Agreed, however at this point in time we are kind of at a middle ground, there are existing modules which already exist. So my idea / compromise is to move them to plugin when they become supported and ready to replace the existing plugin. > Can we retire the existing module after this proposal is accepted? The > only public contract we have here is with the DataStoreFinder; I would > like client code to be able to update smoothly if they used > DataStoreFinder (and if they have used a constructor or something > directly I am okay breaking). This is something i am not sure we have discussed yet, migrating from users using the old data store to the new one. Andrea may be able to answer this. Andrea: what would happen for instance if we took the old oracle driver off the classpath, replaced it with the new one. Would for instance Geoserver configuration continue to work? > > This proposal also does not actually say very much about what is going on: > - you say there is no public api from the client point of view - fair > enough correct. > - should we consider the public api (and the contract you have) with > implementors? perhaps... but i have not seen other proposals go over internal api in detail in this manner. And I don't see all that much gain in documenting the new api in detail in a proposal. I think the javadocs will be effective in doing so. If anything we just need a tutorial which can walk through the process of implemeting a new dialect. > - do not make public class OracleDataStore (it should be package visible > to be created by an OracleDataStoreFactory? There are no subclasses for individual datastores. In fact JDBCDataStore is a final class. > - can we fold this into the existing oracle plugin; and simply make the > factory return the new implementation? Hmmm... we could for oracle since Andrea explicitly avoided a naming conflict. But for instance with mysql there are naming conflicts with the DataStoreFactory. I guess we could rename all the datastore factories similar to how Andrea named oracle... for instance MySLQDataStoreFactoryNG > - there is no documentation changes? can we have an update the the JDBC > DataStore page > (http://docs.codehaus.org/display/GEOTDOC/JDBCDataStore+Developers+Guide) > even if all you say is to use the new class using OracleDataStore as an > example I would prefer we wait on this until it moves toward supported. > > In short - this may be a good idea but from the proposal I cannot tell > what the idea is. > Jody -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
