It seems that we could have a few implementations of LayerGroupInfo etc. for
the express purpose of loading old data dirs - maybe we add a version=
attribute to the root element and have XStream choose the implementation
class based on that, with the fallback in case that attribute doesn't exist
being the last version before we started this scheme. Then these old models
have a way to convert themselves into an equivalent, xstream-ready instance
of the latest and greatest.
It seems like if we provide a backwards conversion this could also help
support a versioned REST API, which would help give us a bit of freedom in
developing useful new features that just happen to be awkward to implement
in a backward-incompatible way (like this one.)
--
David Winslow
OpenGeo - http://opengeo.org/
On Tue, Oct 11, 2011 at 10:48 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Fri, Oct 7, 2011 at 9:01 PM, Justin Deoliveira <jdeol...@opengeo.org>
> wrote:
> > Some thoughts:
> > I would be for a common interface for Layer and LayerGroup... but not
> sure
> > what a good name for it would be... I would also be for just using
> > CatalogInfo if it suffices for this use case.
> > If LayerGroupInfo#layers is going to become a derived property that
> > recursively returns all the leafs of the tree I would like to see it
> > deprecated and renamed to "layers()" to keep with derived property naming
> > conventions. I like either getItems() or getContents() for the property
> that
> > returns only the direct children of the layer group.
>
> Sure, this works.
>
> > You might be able to save yourself some headaches with the REST api by
> > allowing one to POST to an existing layer group the name of a layer / or
> > another layer group, rather than forcing the client to encode the
> contents
> > in the metadata map.
>
> I agree, at least for construction, but I guess that for editing and
> deletion of
> elements there is really no way out?
> Anyways, yes, this is an headache, it seems to me the xstream code will
> have to
> be able to understand both <layers> and <contents> on trunk for put
> operations
> and act accordingly (to preserve backwards compatibility).
> Wondering about GET, do we need to keep on returning both layers and
> contents?
> I guess a simpler way would be to keep on returning layers only and allow
> groups
> to be part of the list?
> The issue with the persistence code is that we cannot do it without
> breaking
> backwards compatibilty :-(
>
> Cheers
> Andrea
>
> --
> -------------------------------------------------------
> Ing. Andrea Aime
> GeoSolutions S.A.S.
> Tech lead
>
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
>
> phone: +39 0584 962313
> fax: +39 0584 962313
>
> http://www.geo-solutions.it
> http://geo-solutions.blogspot.com/
> http://www.youtube.com/user/GeoSolutionsIT
> http://www.linkedin.com/in/andreaaime
> http://twitter.com/geowolf
>
> -------------------------------------------------------
>
>
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure contains a
> definitive record of customers, application performance, security
> threats, fraudulent activity and more. Splunk takes this data and makes
> sense of it. Business sense. IT sense. Common sense.
> http://p.sf.net/sfu/splunk-d2d-oct
> _______________________________________________
> Geoserver-devel mailing list
> Geoserver-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
