[email protected] wrote: > Hi, > > Thanks for the proposal, I just think I'm getting lost though, so excuse > me if I'm getting it all wrong: > > I don't quite see the separation between data and publishing by > layer.xml being inside workspaces/<ws>/<ds>/<ft>/ > > Something like the following would make more sense to me, at least with > the idea I have of how things are supposed to be: > > ... > workspaces/... > namespaces/... > styles/... > layergroups/... > templates/... > maps/ > map1/ > layer1.xml > layer2.xml > layer3.xml > map2/ > layer1.xml > ... > > > If the proposed structure is like it is because that better reflets "how > things actually are now", doesn't that mean another data directory > change proposal will be needed when we finally support more than one > "map" or "virtual instance" or watever it ends up being called like? You bring up a good point. And indeed the map structure you list will be needed once we have the publishing split. The plan as I saw it was to introduce that change when the time comes. And for now keep layer.xml next to the feature type / coverage configuration.
Since the change to the data directory structure will be additive I do not see it as a big deal. We have added directories to the data dir structure as need be before, templates, security, palettes, etc... That said we could adopt this structure now, i would not be against that if people think that introducing it now is the better way to go. > > To be honest I would be more comfortable if we find the way to start > supporting the concept of "map" right now, since implementation wise we > can as easily have a single(ton) map. > But that seems to be topic for a separate discussion cause I already > have some with andrea in person I think. Still, my point is I don't > quite see the reason to have a new catalog design that accounts for the > separation of data and publishing if we don't use it, even if for the > time being there's only one of such "maps". > We could do this but imo it increases scope in the short term. And does not really buy us much since the changes required to the data directory can be done pretty cleanly once we have the map data structure in place. > > My 2c.- > > Gabriel > > > Andrea Aime <[email protected]> escribió: > >> Justin Deoliveira ha scritto: >>> Hi all, >>> >>> As part of recent hacking moving towards 2.0 i have been working on a >>> new data directory for 2.x better suited to our configuration. Here is >>> the proposal. Feedback welcome. >>> >>> http://geoserver.org/display/GEOS/GSIP+34+-+New+data+directory+structure+for+2.x >>> >>> >> >> Generally speaking looks good. A few details: >> - nothing states how the granular saving is occurring (but we know, for >> example, that XStream is used to persist the xml). Citing the >> event subsystem would shed some light on the machinery (also, >> when are the events triggered?) >> - the proposal should say how the old configuration get converted >> to new ones (automatically, interactively, in place or in a >> different directory?) >> - I guess to get that output some of the objects have been >> "massaged" setting up XStream aliases in order to get >> better looking output? >> The wfs.xml "gml" section looks confusing, I cannot really make >> up what that is... >> - in featureType.xml, do we actually need the list of attributes? >> We should be able to make the list up by looking at the native >> schema and the schema.xml files. (eventual mapping information >> will be stored in a layer configuration, and is anyways out >> of scope with the current state of the art right?) >> - what about the freemarker templates? >> >> Cheers >> Andrea >> >> -- >> Andrea Aime >> OpenGeo - http://opengeo.org >> Expert service straight from the developers. >> >> ------------------------------------------------------------------------------ >> >> >> 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. ------------------------------------------------------------------------------ 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
