WRT storing the tile layer configuration as part of the layer/group metadata map:
The more I think about it, the more I'm inclined _not_ to store the tile layer config as part of the metadata map. As it evolved enough as not to be any "simple" property of the map, I think trying to make it fit is overkill and it would rather be better a gwc only thing, like in gwc being in charge of maintaining that configuration on its own, rather than squeezing it into the metadata map. Rationale: - People using the geoserver REST API will (rightfully) try to configure the tile layer through the layer's REST resource instead of through GWC's REST API. - Not all layers may be configured with an associated tile layer, which kind of forces gwc to do a full scan of layers just to find out which ones have the config on its metadata map. - The REST representations of layers and layer groups would be unnecessarily bloated Rest assured having the tile layer configuration so close to the layer/group is "handy". Specially because of the monolithic gwc configuration file, which would have to be overridden as a whole every time a layer config changes. Which makes me think that perhaps we could get the better of both worlds by keeping the geoserver tile layer configuration as a separate file next to the layer.xml or layergroup config file instead, as there's no room at least on the gwc stable branch to change its configuration subsystem to stop being monolithic. Thoughts? TIA, Gabriel On Thu, Jan 26, 2012 at 9:32 PM, Gabriel Roldan <grol...@opengeo.org> wrote: > On Wed, Jan 25, 2012 at 10:33 AM, Andrea Aime > <andrea.a...@geo-solutions.it> wrote: >>> Now, while enabling to >>> configure almost every aspect of the cached layer, instead of storing >>> a single metadata entry for each cached layer property, I'd rather >>> store the whole tile layer configuration as a single metadata entry, >>> in its JSON representation. Earlier experience in doing that is the >>> storage of AuthorityURLInfo as a JSON entry in the LayerInfo and >>> LayerGroupInfo metadata map, and it seems to be working well. So if >>> there's no opposition I'd store the tile layer configuration as a >>> single JSON entry in the metadata map, allowing for the natural >>> evolution of the cached layer configuration without extra bloating of >>> the metadata map (backwards compatible with the current set of >>> entries, of course). >> >> >> Works for me. Wondering, why JSON and not XML? >> If you look at SQL views setups they are stored as xml instead, making >> it look more "natural" if you look at the xml file (which you will see when >> using rest config) and won't require mixing technologies when building >> rest requests. > > ok, but: if my understanding is correct, in order to do so I'd need to > register an XStream Converter inside XStreamPersister. For > VirtualTable and everything else so far it's been easy because they > were added directly. But the gwc integration has the "philosophy" of > being pluggable/decoupled, which makes this trickier. > First option I can think of is an extension point, say, > GeoServerConverter, that the XStreamPersister.init() method looks up > for and registers all found implementations to the XStream instance. > That is step one. But what happens if this custom gwc converted > follows the same approach than the VirtualTableConverter > (e.g. <entry name="GWC.tileLayer"><some><customXml/></some></entry>) > and then the gwc jars are removed from the classpath, including the > geoserver's gwc integration jar. Wouldn't that mapping bomb? > > While most of you sleep, I'll try to find out. > > Cheers, > Gabriel > -- > Gabriel Roldan > OpenGeo - http://opengeo.org > Expert service straight from the developers. -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
