[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Re: Catalog / Layer contract, was UDig on Windows XP
|
Hi Jody,
thank you so much for this mail. I thought the irc would not take
place beeing you guys all very busy, but it seems I lost one of the
most "abstract" IRC ever. Is there a log around?
I will go through your mails and come back to that.
Andrea
On Dec 13, 2007, at 7:40 PM, Jody Garnett wrote:
Morning Moovida; this email is a replacement for your Thursday IRC
meeting ;-)
It seems that there has been a break down of trust between the
project and the catalog layers of our application. I was not aware
of this change when it was introduced, it seems that the project
plugin is using both:
- "layer id" to look up an entry in the catalog; and
- it was also using the connection parameters
There is a relationship between layer id, and connection parameters.
They need to be exactly in sync or the catalog starts getting
confused.
I was surprised that this was even possible - here is how it was done:
- IServiceFactory.acquire( id, params )
The javadocs for this method say: "is intended to be used when
replacing an IService entry in a catalog". This method is used by
the catalog framework when setting up for a replacing a moved
service, ie it is a step that is needed when we are about to fire a
REPLACE event.
So what has happened is when lazy loading of a map was introduced;
maps were no longer around to listen to REPLACE events and thus
could not be kept in sync with the catalog. The above acquire method
was used to allow these out of sync map layers to fumble along using
an ID that did not exactly match the intrinsic identity of the
resource on disk.
This amounts to a breakdown of trust between the two systems :-) The
concept of an ID is no longer trusted by layer to a be a good handle
for resource lookup; this is something we can fix.
I would like to introduce a "IForward" class into the catalog;
something that can be left behind in the catalog when a resource is
moved. That way projects that were closed still have a way of
noticing and fixing themselves when they are loaded. These handles
can be used just alike a IService returned from a search; they can
act as a wrapper for the actual service (so simple code can stay
simple), although I will make them printin warning messages if uDig
is being run in -debug mode.
It is my hope that with this addition trust can be established again
and the project layer implementation can be simplified, and made
much less insane ;-)
Jody
