Re: [udig-devel] IGeoResource questions from development land

[Jody Garnett <jgarnett@xxxxxxxxxxxxxxx>]

Jesse Eichar wrote:
> > - Catalog "events" with getInfo( ... ) granularity; this is needed. 
> > Making the catalog event system extend down to the information 
> > available via ServiceInfo is not a bad thing
> Agreed.
How about we do this after the next release candidate?
> > - IGeoResource.parent( monitor ) - returns a IService (which is 
> > wrong, and has been wrong and fixed three times - is now the time for 
> > the fix to stick?)
> Going forward this is a great idea.  WMS have a hierarchy and this 
> will allow that construct to make more sense.
>
> > - IGeoResource.service( monitor ) - if this method is needed it can 
> > be added ... although a quick loop with parent would produce the same 
> > effect
> sure
The above parent / service methods are a package deal - commit being 
applied now. We will save revealing nested WMS layers and database 
schemas until a future release?
> > - IService / IGeoResource "warnings"; right now we have one single 
> > Throwable, all implementations make use of this Throwable to only 
> > talk about the "preferred" - ie why getStatus() == BROKEN. We need 
> > something in user terms; no doubt attached to the info objects
> Something easy to access and implement is needed.  This is critical 
> for uDig because right now we have no consistent way to indicating to 
> the user what issues there may be with the configuration.
So we need to get a change into the mix at the GeoTools level:
- Use their GeoResource / GeoResourceInfo objects to get the job done?
- Pass in something to the connection process like a ProgressMonitor 
that can collect the warnings...
(We should also make use of their "internationalization" support; so we 
can punt in warnings that are expressed in user, and udig, terms)

I would like to see the warnings stored as either; "session properties" 
(see below), or as additional methods available on IResolve (we can 
deprecate the use of a raw Throwable as shortsighted). I had thought of 
attaching these to the Info object; but frankly the info object is not 
the one that had the problems and it would be best to leave it as pure 
metadata.
> > - IService.dispose() - seems to be required; it is too bad the 
> > concept cannot hidden to local catalog - rather then something user 
> > code *must* call
Thinking this through I would like to replace the idea of dispose() with ...
- use of session properties for caching things like the actual DataStore
- offer a properties + lifecycle = blackboard
Once again lets wait until the next release candidate; can I confirm 
that dispose was only added for uDig 1.1.x?
> > The following ideas from IResource have also been requested in the 
> > last year:
> > - IService / IGeoResource "session properties"
> > - IService / IGeoResource "persistent properties"
Can we should consider session properties for uDig 1.1; and leave 
persistent properties until later.