[Geoserver-devel] R: But we have a repository already?

P.Rizzi Ag.Mobilità Ambiente wrote:
> Anyway what we really like to do is working against a repository
> of FeatureTypes/FeatureSources as a whole and irrespective of their
> actual parent DataStore. It would also be great to support
"mirrored"
> sources, where the repository will access the "best"
available source
> as you described in your wiki.

I should clairify that GeoTools already has this interface,
called Repository:

-<http://udig.refractions.net/docs/api-geotools/org/geotools/data/Repository
.html>

This interface is used by GeoServer to present exactly the information you

describe to the Validation Processor. It is designed to hold cross

datastore

opperations such as lock management.

From what I see it seems GeoServer isn't really using it.
It uses it from the Web admin interface when you press the button
to test the validation, but not inside TransactionResponse, where
the real validation takes place.
Also, apart from the interface, what counts are the implementations,
and the existing two, DefaultRepository and FeatureSourceRepository,
are both commented as "...Quick hack of a DataRepository...".

Feel free to patch it up with other cross DataStore opperations as

required.

Your above intentions, are in to words "right on", and this is the

interface for

them.

Sure there are many more operations to be added, basically everything you
can do
on a single DataStore (both reading and writing) should be doable against
a repository as well.
But I don't think adding all the operations to a single interface is the
right
way to go. I feel we may need something more flexible, perhaps pluggable.
Maybe I should not say "...against a repository..." because I really mean
two things.
There's a Catalog that knows metadata about FeatureTypes but doesn't have
any operation.
And there's what we call a DataEngine that knows how to operate on data
using the Catalog as a source of information. Maybe the combination of the
two
can be called a repository, but I like them to be separated.

You may be interested in how the different forms of data access fit

together:

-<http://udig.refractions.net/docs/uDig-DataAccessGuide.pdf&gt;

Has an outline - current as of last Winter.
Jody

      Bye Paolo