Jody I took a deeper look to Catalog interface and I got dazed and confused.
Again I agree on having a central repository interface but a redesign is not a matter of adding some methods. Some thoughts 1) I am missing the clean concept of namespace handling 2) It must be possible to write a Repository implementation acting as adapter for the geoserver catalog (supporting the workspace concept, which I think we could handle with 1). The same must be possibile for UDIG. The interface implementation must be configurable externally, we need something like a "RepositoryFactory". 3) Unlucky naming of methods, "source" as an example. You must look at the source code to have an idea what this method is doing. Missing methods, how to get a datastore with his name and namespace ? 4) No idea about the locking methods, I think nobody calls them, and btw, I would delegate the locking to an external locking manager. And why should a repository do locking at all ? So, I think we would a least need RepositoryInterface RepositoryFactory RepositoryImpl for geotools RepositoryImpl for geoserver RepositoryImpl for udig ? This would be a real improvement but it would block me for weeks. I am already blocked here because I want to finish the feature-pregeneralized tutorial and ask for geoserver integration. As a proposal, I would like to continue with the DataStoreLookup and mark it depricated as soon we have implemented a cleanrepository concept. christian Jody Garnett writes: > A couple of comments > - Having an interface to allow geotools to look up something in the > geoserver catalog is the he point of the repository interface. So if > geoserver has changed we need to ensure this interface is updated so > geotools code can hook into it. > - I do not really want the repository interface as it stands to block > your work; lets modify it to suit your needs. > - I do not really want duplicated work; you will need an > implementation of your DataStoreLookup anyway to have test cases in > geotools right? > > So lets use your DataStoreLookup interface as a request to modify > Repository. Does it represent exactly what you need ? Is it missing > anything that is needed? > > Jody > > On Wed, May 13, 2009 at 10:41 PM, Andrea Aime <aa...@opengeo.org> wrote: >> Christian Müller ha scritto: >>> >>> I wanted to use the org.geotools.data.Repository (life would be easier) >>> but this would not work for geoserver. >> >> Wondering if it's not possible to make a GeoServer plugin that wraps >> the GeoServer catalog into a Repository interface? >> >> Cheers >> Andrea >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> ------------------------------------------------------------------------------ The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
