[email protected] ha scritto: > 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? > > 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".
Maybe there is still a way to accomodate both. During the discussions about maps the point that not everyone needs them was made, and that we should support the extra complexity, but not force it onto the users that have no need for it. The idea was to have a default map that lists all of the layers in the configuration, using a default layer configuration. The same default can be used as a template if you need to provide the same layer, or group of layers, in multiple "map" instances (treating it like a pointer). So we could say the proposed structure represents the default map already, and that the maps configured are only the explicit ones, beyond the default one. Anyways, I'm not against the separation, as we said the data directory layout in not intended for direct manipulation, I'm more concerned about a smooth upgrade path and a simple setup for simple usages than about a particular data directory layout. 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
