On Thu, Jun 2, 2011 at 3:50 PM, Gabriel Roldán <groldan@anonymised.com> 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 <groldan@anonymised.com> 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
-------------------------------------------------------