[RFC-24] USE_MAPSCRIPT configure flag

[Tamas Szekeres]

2007/5/23, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
>
> The cgi app does not need rfc24 because it does not add dynamically
> layers at runtime (except for the special cases of the legend and
> scalebar), and to keep the cgi running at the highest speed possible
> rfc24 adopts the special USE_MAPSCRIPT flag to remove the unneeded
> reference counting.
> Anyway, the cgi compiled with USE_MAPSCRIPT works exactly like before,
> maybe a bit slower.
>
> I have no objections on enabling mapscript by default if most of us agree.
>

I think we should give some help in the decision when to enable this
option. For example currently ms4w supports the cgi application as
well as the various mapscript bindings. Which option should Jeff use
to continue supporting both in the ms4w package? Or should he separate
the builds related to the targets and eventually provide 2 versions of
the libmap.dll (a mapscript and a non mapscript version)
I think USE_REFCOUNT instead of USE_MAPSCRIPT would describe better
the effects behind this setting.

> > This option should also be added to the windows makefiles through nmake.opt.
> >
>
> I'll look into it, even though I have no experience with Visual Studio.
>

I volunteer to make this addition upon the buildbot reconstruction
after these changes :-)

> > Is the RFC-24 complete with these changes? How about '3.6 Always give
> > object ownership to SWIG' for example?
>
> RFC-24 should be done with regard to the objects marked so in the
> tracking tables at the end of the rfc.
>

How would you organize this work. In my understanding the lack of
these additions would result in memory leaks with the corresponding
languages, right?
Am I right that only the mapObj, layerObj, and classObj were affected
by this reference counting approach. In this regard should the other
classes retain the original behaviour by not taking the ownership
every time?

IMO every class that might be a child of another should also be
handled somehow.  Destroying the parent will also destroy the
referenced memory of the children. Should those be treated by the
various bindings? Do you have a reference implementation for this?


Best regards,

Tamas