Justin Deoliveira wrote: > Hi all, > > I am looking at using the catalog api that was ported to geotools some > time ago in GeoServer. Looking at the api I have some thoughts that I > would appreciate feedback on. > > 1. Client properites for Service, and GeoResource handles. > It would be nice to associate application specific information such as > namespace prefixes, etc.. with a resource or service handle. This is part of the Eclipse IResource API, we did not use it in Catalog as it was not needed right then. I would still wait for a request on udig-devel from an author of a client application before adding them in.
The reason we wrote the catalog interfaces was because of the lack a suitable "handle" interface for networked resources, that need may finally have been met as the "Common Navigator Framework" is available (links sent to uDig list although here is one http://scribbledideas.blogspot.com/2006/06/what-does-common-navigator-framework.html). Answer review common navigator framework and do what they do ... > 2. Mutability of metadata (*info) interfaces. > > Does it make sense to have these interfaces be mutable. Some of the > metadata elements dont really make sense to be published by the > service itself. An example would be publisher, or abstract. Not sure about making them mutable, I would rather they were a nice view of information already maintained by the "data source" (say in a header or a metadata header), and such things are not always changeable - but perhaps an "override" should be allowed? Things like publisher or abstract come from first GeoServer needs (think of GeoServer's FeatureTypeInfo class ) and then the "dublin core" metadata standard, and are very useful when searching... So mutable, if you can get me an "info" interface at the same level as DataStore. Publisher & Abstract - heck yes. > 3. Visitor > > Marching threw the catalog and testing each handle gets kind of > tiresome. It would be nice to have a visitor to abstract a lot of this > away. For the specific application or handling events a visitor has been defined, but rather then marching through the catalog some sort of search operation should be used. Once uDig moves to geotools trunk we could allow the use of filter to perform these searchs (against the info objects) and return the matching IResolve handles. So search rather then visit :-) Jody Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
