On Thu, Dec 6, 2012 at 6:24 AM, Andrea Aime <[email protected]>wrote:
> 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?
>
Right... i guess it would help to know what the classpath overhead is in
terms of additional dependencies, etc... of the internal store is. As far
as i can see it looks to be pretty minimal, no additional libs and just a
handful of classes.
@Niels: do I have that right?
>
> 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.
>
> So a single module containing all backend implementations? Not sure how i
feel about that once other implementations start pilling up that could
potentially add overhead in terms of dependencies, etc... The composite
idea makes sense though but should be orthogonal to 1 module vs many
modules. If i understand it correctly.
>
>> 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).
>
I see. Well what if we built the catalog purely around the CSW cite data,
similar to how we setup the cite data for testing the other services. Or
does the cite test data contain more than just "layers" that need to be
returned?
>
> 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
>
> -------------------------------------------------------
>
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
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
