RFC-24 Mapscript memory management: call for votes

[Stephen Woodbridge]

Umberto,

You have done an awesome job with this complex RFC, Thank you. Also 
Thanks to Tamas and other that have contributed with their review on the 
technical aspects. This is an important change to go forward with for 
all mapscript users.

I think there is one thing that is missing, or I missed it:

   What is the impact on the the language from a backwards compatibility
   point of view? For example, do these changes represent a change to the
   language that would require people to change existing working scripts?
   If so, what are the changes? This should drive any doc changes that
   will need to be made. If there are not changes expected, then that
   should also be stated. Obviously this fixes a lot of bugs and issues
   but I'm more concerned about providing the info for people to plan
   their migration to this new code if additional work is required.

Primarily what I am looking for is some indication what will need to 
change if anything in existing Perl or Java mapscript application since 
these are ones that you are familiar with. Obviously the other 
maintainers will need to add it for there respective languages. I think 
this has been discussed in the dev threads for this rfc, but I think it 
should be summarized in the RFC.

+1 with a section on compatibility/language changes added to RFC

-Steve

Umberto Nicoletti wrote:
> I took some time to update the RFC text at:
> 
> http://mapserver.gis.umn.edu/development/rfc/ms-rfc-24
> 
> to reflect the latest changes introduced in the recent discussion
> thread with Tamas.
> 
> The purpose of rfc-24 is to make object manipulation safe in mapscript
> to allow for dinamic layer/class creation/addition to a new or
> existing map. The problem it adresses with regard of these issues is
> only related to memory management and not to thread safety. So the
> implementation of this rfc will NOT make it safe to execute
> functionalities of mapserver that are known to be thread-unsafe, but
> will make it possible to manipulate on-the-fly mapserver object
> (initially only some, eventually all) to provide more interactivity to
> mapscript-based maps.
> 
> It should be noted that the rfc only deals with swig-based mapscripts,
> so php is left out, but I believe that, since most of the code has
> intentionally be kept in the C layer, php maintainers will be able to
> integrate this rfc quickly (WARNING: once this rfc has been adopted
> php mapscript will have to be updated, as rfc-24 is not opt-out). The
> rfc also mandates some changes to be done in a customized fashion for
> each mapscript language (item 3.2), but this is absolutely necessary
> and all effort has been put into keeping the number of changes to the
> minimum.
> 
> A a side benefit of choosing to implement this rfc the layers, class,
> style arrays will be converted to arrays of pointers instead of arrays
> of structures with a substantial memory saving on great values of
> MAXLAYERS / numlayers and better/faster manipulation.
> 
> I would also like to point out that at time of this writing the rfc-24
> has a functioning implementation for most items except 3.2 which is
> readily available as a series of incremental patches at
> 
> http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=2032
> 
> so I believe we are halfway through already.
> 
> Conflicts with your current work: this rfc is likely to break
> some/most of the changes you're working on locally. Luckily most
> changes introduce by this rfc can be re-applied by the use of
> perl-pies that I have readily available.
> The impact of the changes should be rated HIGH as it is at almost
> every level of mapserver code.
> 
> Testing: I have written a python unit test (available in bugzilla) for
> every mapscritp method that has been reworked, but I'll also need some
> help with running the msautotest suite and anything else that's
> available to ensure maximum correctness.
> 
> This RFC is the result of many months of work and, while it is a major
> change with high impact on existing code, I also think it is badly
> needed by most mapscript users who expect it to be able to dinamically
> manipulate layers, classes, etc. The release of mapserver 5 would be a
> perfect timing for delivering this new functionality to
> mapserver/mapscript users.
> 
> It is definitely a +1 for me ;-)
> 
> Waiting for your votes,
> Umberto