Jody Garnett wrote: > 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. > I beleive I just did. However I am refering to the geotools catalog not the udig one. > 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. Sorry, this rant didn't quite make sense to me. How is the "override" acheived?
> >>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. > My usecase was more along the lines of searching for handles which resolve to a specific object. Searching a complex tree of objects like the catalog screams visitor to me. Allows for more flexibility imho. > 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 > > !DSPAM:1004,44a3c64d7238365517736! > -- Justin Deoliveira The Open Planning Project [EMAIL PROTECTED] 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
