Chiming in with an extra concern and a suggestion, on different topics though: - concern: what about two files in the same directory, different format, same feature type name: roads.shp and roads.properties. Namespace seems like not enough to handle that.
- suggestion: about how to identify if a given DataAccessFactorySpi works upon files. We already have immutable datastore parameters where needed (dbtype?). Also, we have this new param metadata information coming from DataAccessFactory.Param extending org.geotools.data.Parameter. Param.isPassword() being just a convenience method to get to a parameter metadata field. We could use a parameter convention for file datastores, being the parameter both immutable and holding a Boolean metadata field stating it works upon files instead of database or remote service or whatever. Then, the DirectoryDataStore could get all the factories that work on files, figure out which param is either a File or an URL and ask them if they canProcess(...) first the directory and then a given file. Or better, the URL or File based datastore may contain a metadata field indicating whether it expects a directory or a file.... just thinking loud, but may be of help. my 2c. Gabriel On Thursday 11 December 2008 21:30:50 Justin Deoliveira wrote: > Andrea Aime wrote: > > Andrea Aime ha scritto: > >> Can we hit a compromise of any kind so that something can be done > >> on 2.5.x? My enthusiasm on this directory datastore remake has > >> suddenly dropped below zero, as I've seen this movie already... > > > > Hum... datastore dispose wise I was probably thinking too much. > > If we have a weak reference based cache and we assume that > > the client code has to let go of the FeatureSources before > > we can consider the datastore disposable, then we're probably > > already good, as all FeatureSource have strong back reference > > to the DataStore -> the weak reference should not die until > > there is a strong one to the same object around, isn't it? > > If you make the parallel, it would work exactly like ResourcePool > > in GeoServer, the problem is the same, cache the datastores since > > it's expensive to keep on create them, but not keep around > > too many of them either. > > > > If so, for 2.5.x we can avoid the need to alter the FeatureSource > > API. Same goes for the FileFeatureSpi interface, the first > > re-implementation on 2.5.x can assume the two working conventions > > of 2.5.x file based data stores, File + namespace or URL + namespace, > > and on trunk we can roll a new interface (and in the meantime, > > we can deprecate the file related interfaces in 2.5.x). > > > > What do you think? > > Hmmm... yeah I guess you are right, we were thinking to hard :). Sounds > good to me. > > > Cheers > > Andrea ------------------------------------------------------------------------------ SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
