Rob Atkinson wrote: >> I am ok with putting these files in the services directory but whether they >> are at the top level or in a sub directory really makes no difference to how >> they will be read. The existence of the file does not mean the service is >> active, and vice versa. > > Understood - it wasnt about the functionality, but simply not setting > a number of particular services in stone and needing changes to > directory structure to add any more (a top level file is part of > directory structure according to the scope of this request) Cool, sounds good, services directory it is. > >>> 2) We are still burying database connections deep, and not re-using >>> them. I'd like database connections and other local configuration to >>> be normalised and re-used. >>> >>> can we have a top level directory connections/ or authorisations/ >>> >>> This is a real issue when we distribute a re-usable Geoserver >>> configuration via version control - with multiple geoservers >>> delivering common stuff - INSPIRE for example would require this. >>> There may be an element of local mapping - but we actually found that >>> was often encapsulated in database views and it was only multiple, >>> buried, not-separately-testable database connections that needed >>> configuring. >> While I agree with the concept I want to reinforce that this proposal is not >> proposing any improvements to the configuration, and is not proposing any >> new information to be stores in the dat directory. It is just a >> reorganization of the information that is already there. >> > > OK - so if this is not going to make it harder to fix this later, you > have my +1 officially. > > >> We don't store this info in config today so this is out of scope. >>> 3) It is important that namespaces be "augmented" by explicit >>> declaration - the general case is that the target configuration >>> exposes a namespace as part of a contract between the service and the >>> world of clients. It should be possible to "make this up" during >>> FeatureType configuration, or use one extracted from the definition of >>> the FeatureType (the application schema case). Its not clear to me if >>> this is an issue - probably an implementation issue, not a directory >>> structure issue >>> >> You lost me on this one :). >> > > Manually defining namespaces during configuration is a corner case in > the long run. These will always be defined in application schemas, or > can be generated automatically without user configuration if they have > no external meaning. So, just want to avoid putting too much effort > into something I think needs fixing. Ahh I see, and yeah I fully agree. This is the motivation behind the workspace idea, have it be a container for data stores, etc... and have a namespace just be an attribute of a feature type. Ideally the way it would work is as you say, upload a bunch of application schemas, figure out the application schema namespaces, and choice one when setting up a feature type. > > >>> Sorry to provide feedback so late. >>> >>> Rob Atkinson >>> >>> On Wed, Mar 18, 2009 at 10:40 AM, Jody Garnett <[email protected]> >>> wrote: >>>> Thanks for the nice clear presentation - I am happy to vote +1. >>>> >>>> I would consider: >>>> global.xml >>>> service/wfs.xml >>>> service/wms.xml >>>> service/wcs.xml >>>> service/wps.xml >>>> >>>> But it does not make much of a difference. >>>> >>>> Jody >>>> >>>> On Wed, Mar 18, 2009 at 6:17 AM, Justin Deoliveira <[email protected]> >>>> wrote: >>>>> Hi all, >>>>> >>>>> I would like to call for a vote on GSIP 34: >>>>> >>>>> >>>>> http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x >>>>> >>>>> Most feedback as been incorporated but the proposal of adding the idea >>>>> of maps into the picture has not been incorporated for now. The reasons >>>>> why being: >>>>> >>>>> 1) It increases scope in the short term without a lot of gain. Since the >>>>> the upgrade to including maps into the picture is strictly additive to >>>>> the data directory structure, it won't be an issue to add it later. >>>>> Implementing maps in the short term, even just creating the idea of a >>>>> default map is not trivial, and adds a pretty big hurdle. >>>>> >>>>> 2) Andrea pointed out that the data publishing split with regard to maps >>>>> has not totally been fleshed out at this point. And indeed there is some >>>>> thoughts about using a thread local view of the catalog as an >>>>> alternative. So adding in maps to the structure now could indeed be a >>>>> crutch come later. >>>>> >>>>> So that is the rationale for leaving it out of the picture for now. >>>>> Those who stand by the feedback still can vote -1. >>>>> >>>>> So with that said, let the voting begin. >>>>> >>>>> -Justin >>>>> >>>>> -- >>>>> Justin Deoliveira >>>>> OpenGeo - http://opengeo.org >>>>> Enterprise support for open source geospatial. >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >>>>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >>>>> easily build your RIAs with Flex Builder, the Eclipse(TM)based >>>>> development >>>>> software that enables intelligent coding and step-through debugging. >>>>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >>>>> _______________________________________________ >>>>> Geoserver-devel mailing list >>>>> [email protected] >>>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>>> >>>> ------------------------------------------------------------------------------ >>>> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are >>>> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and >>>> easily build your RIAs with Flex Builder, the Eclipse(TM)based >>>> development >>>> software that enables intelligent coding and step-through debugging. >>>> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com >>>> _______________________________________________ >>>> Geoserver-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>>> >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >>
-- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
