[Geotools-devel] [udig-devel] Throughts on catalog api

[Justin Deoliveira]

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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
> 
> !DSPAM:1004,44a3c64d7238365517736!
> 


-- 
Justin Deoliveira
The Open Planning Project
jdeolive at openplans.org