On Wed, Dec 5, 2012 at 10:38 PM, Justin Deoliveira <[email protected]>wrote:
> I was thinking that once the "internal" store was completed it would be
> basically included with the core module, and serve as the default so that
> without more or less zero configuration you could fire up geoserver and
> have a working csw. If others agree with that approach the name "default"
> probably makes more sense than "internal".
>
> To facilitate the plugging in of other stores like the simple one we could
> get fancy but something similar to how the ResourceAccessManager for
> security would work. Basically we do a look up for CatalogStore interface
> in the spring context, and if one is not found we fall back on the internal
> one.
>
> So with that the module structure would be:
>
> csw/
> api/
> core/
> simple/
>
I am twisted about this one, there are a few ways to skin this cat, not
sure this one is the best.
First option, keep the modules as separate as they are today, but include
in the release zip only the internal store, leaving the other available
as an example for developers (and for running cite tests).
You drop in the store you want, you go with it, pretty simple.
Advantage:
- if you are building a custom GeoServer with a custom catalog, you don't
have to carry around needless
baggage (btw, the ISO bindings should be in api though)
Disadvantage:
- a bit rigid, what if one wants multiple catalog sources?
Second option, the one you propose. Similar to the above, wit the extra
baggage in the classpath
Third option, do as one (all stores out by default), but put in the
extension package all implementations
and create a "composite" store and make thing configurable by the admin:
a GUI allows to list the implementations and choose which to enable and
which leave dormant,
this one might have both the internal store and some external ones too.
> Also there is a test dependency from the core module on the simple module
> for testing purposes. I think it probably makes sense to refactor all the
> test cases that currently use the simple store into a set
> of abstract classes that remain in core. And then simple and default would
> both implement all the test cases to get the same coverage. More or less
> how we do jdbc datastore testing in GeoTools.
>
Hmm... don't think this is going to fly, the CSW tests are assuming the
CITE test data is available, but
one can have it only if you have around a store allowing to choose the
input data (the internal one
is locked onto the layers instead).
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
