RFC-24 Mapscript memory management: call for votes

[Umberto Nicoletti]

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