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".
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
>
------------------------------------------------------------------------------
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
