> > 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) >> 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. >> Sorry to provide feedback so late. >> >> Rob Atkinson >> >> On Wed, Mar 18, 2009 at 10:40 AM, Jody Garnett <jody.garn...@gmail.com> >> 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 <jdeol...@opengeo.org> >>> 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 >>>> Geoserver-devel@lists.sourceforge.net >>>> 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 >>> Geoserver-devel@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/geoserver-devel >>> > > > -- > 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 Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
