RFC 19: style and label attribute binding...

[Stephen Woodbridge]

Steve Lime wrote:
> Hi all: I put some ideas to paper base on the thread yesterday as RFC
> 19:
> 
> http://mapserver.gis.umn.edu/development/rfc/ms-rfc-19
> 
> The change really isn't that bad, but is probably a 5.0 modification
> (which could be our next release).
> 
> Steve
> 

Steve,

This sounds like a very straight forward implementation that is easily 
extensible to other attributes. It looks like bindings will only be 
implemented within the layer/style objects, but not class objects which 
I assume is because those fields that could be bound are all deprecated 
and should be in style style.

Do you have a list of bindings that you plan to implement in this 
initial implementation? Are there items people might reasonably think 
should have bindings that you plan to NOT implement for any reason? Like 
in the CLASS object.

Backwards compatibility:

I think is a more rhetorical question that needs to be discussed.

On the one hand, it seems it would not be difficult to to maintain the 
existing angleitem, xxxitems fields and mapscript interfaces, but to 
change them to use the new implementation in addition to adding the new 
interfaces you describe and thus NOT brake Backwards Compatibility.

On the other hand, IF we are going to brake Backwards Compatibility, 
then I think we should clean up a lot of stuff and remove the deprecated 
items that make the mapfile and mapscript complex because there are 
multiple places that key words can be used, but the code only works for 
some new features if you use one of the items and not the other, like 
anti-aliasing requires you to use the style object and not the class 
object to define you styling. I think clean up mapscript and the mapfile 
while painful for some users would have the benefit of a cleaner, 
smaller, more rational implementation.

This also raises in my mind the need for a clearly stated feature 
supported/deprecated/removal policy and an old version support policy. I 
think we have most of that in that we try to act in consistent manner 
from release to release and maintain backwards compatibility except on 
major releases. But we do not seem to have a policy on feature 
deprecation and obsolescence and removal. This is probably because we 
rarely if ever remove features.

-SteveW