Thanks for the feedback Andrea, a few comments inline. Andrea Aime wrote: > 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?) Updated. I added two sections near the end of the proposal which should provide a bit more info. > - 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... Agreed, it is confusing. The wfs info class holds onto a map of GMLInfo, keyed by version. This is indeed something i have not "massaged" yet. That said I am not too worried about making it look all that pretty because people should not be mucking with these files directly now that we have a rest configuration api, although i realize that we don;'t have one in place for service configuration yet.
So, will opening a ticket to make it look nice do for now? > - 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?) Technically we could omit them yes, since the check for a schema.xsd override is checked on startup. That said persisting them might be a good idea with regard to the future. With the attributes persisted in the xml file a user could edit that file directly (yes I know i just discouraged this :)) rather than hacking out xml schema which is verbose. Also if we ever wanted to provide a simple user interface for attribute editing (one that has nothing to do with xml schema) then this would require we persist them. Regardless, if you feel strongly we can make sure they are not persisted. > - what about the freemarker templates? Added to the proposal. Works the same as 1.x. > > Cheers > Andrea > -- 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
