Justin Deoliveira wrote: > 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. As such; if the modules are still unsupported; the only person you need to answer to is yourself. Proposal would be over kill. > 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. Sounds good; and if we can pay careful attention to hiding the implementations from client code it would be helpful. > 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? Depends on the connection parameters; but you should be good to go. You may want to adjust the connection parameters when loading an old configuration? >> - 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. Actually the last proposal for implementors is here: - http://docs.codehaus.org/display/GEOTOOLS/Improve+CRSAuthority+Concurrency+Caching+and+Connection+Use And it mentions a lot of details in class diagrams; sequence diagrams; performance tradeoffs and so on. > 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 You could even keep the current DataStoreFactory and have it choose which implementation to construct based on parameters; this is how the ShapefileDataStoreFactory handles things. As an example - when the indexed shapefile experiment ended the datastore factory had the responsibility to create the most appropriate implementation - any code that was using the API correctly suddenly gained index support (if an index was already present). >> In short - this may be a good idea but from the proposal I cannot >> tell what the idea is. If the proposal really is just to move your code around in the unsupported folder; you do not need a proposal to make the change - only permission from a PMC member. GeoTools *process* only kicks in when you make a commit about the code to others.
Happy hacking, Jody ------------------------------------------------------------------------- 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
