On Thu, Jun 2, 2011 at 3:50 PM, Gabriel Roldán <grol...@opengeo.org> wrote: > On Thu, 2011-06-02 at 09:15 +0200, Andrea Aime wrote: >> On Thu, Jun 2, 2011 at 5:32 AM, Gabriel Roldán <grol...@opengeo.org> wrote: >> > I'm up to implement this. Question is what would be preferable, a new >> > list property in WMSInfo for the blacklisted mime types, or just use the >> > WMSInfo's metadata map? >> > >> > Being something that goes in "core" wms I'd say the correct thing to do >> > is to roll over a new property. Opinions? >> >> I would go core if you implement it only on trunk, metadata if you want >> to backport it to 2.1.x too. >> >> For time and elevation support I'm adding 8 new properties, all in the >> metadata exactly because I want to backport it to 2.1.x, where, _I believe_, >> changes in the config and xml serialization structure are not welcomed. >> I may be wrong. > hum... just thinking about it... if it's core I'd rather prefer them to > be in core and keep metadata for "contributed" content, like geosearch > indexed property and the like. > Off the top of my head I can't think of a reason why de/serialization > would fail, but if you're afraid of breaking something in core, do you > think it'd be a viable solution for 2.1.x to add the properties to the > interfaces but make them delegate to the metadata map in 2.1.x and > proper fields in trunk? > Though that'd be problematic when upgrading a data dir from 2.1.x to > 2.2.x, at least the loader takes care of the upgrade... > Also, if you stick to metadata then you plan to never bring those > time/elevation properties to the core interfaces? > > Just thinking out loud, but yeah, I guess I'd prefer your core > properties being in core too.
The rationale here is that people often go back and forth between versions in the stable series, they see something they want in version x.y.n+1, upgrade, find there is a regression in something that matters, boom, they cannot downgrade because GS won't start up anymore, as XStream finds elements that cannot be mapped to any object property. We already get a number of complaints about that going from x.y to x.y+1 (same reason, people that want to go forward and go back) but at the very least at that point they are upgrading to something that is meant to be functionally different. x.y.n+1 is supposed to be a patch release instead, we tend to mix new functionality, but at the very least such functionality should not introduce significant configuration changes. Now, the point would be moot if it was possible to configure XStream to ignore those new extra tags. Which is something I tried to do in the past, and failed, the patch worked but had very bad side effects (can't remember which ones unfortunately, it has been quite some time ago) 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 ------------------------------------------------------- ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
