RFC-24: request for further comments on item 3.1

[Tamas Szekeres]

2007/5/31, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> All,
> in a previous thread (Subj: [RFC-24] USE_MAPSCRIPT configure flag ) I
> attached a patch to let you preview the implementation of item 3.1 (in
> particular the USE_MAPSCRIPT flag) before I actually committed it (I
> am attaching same patch to this mail again).
>
> Tamas suggested that we drop the need for USE_MAPSCRIPT and let
> refcounting always enabled on the following motivations:
>
> 1) with the advent of use_mapscript the compilation process will be
> different if the user needs to build mapscript rather than the cgi.
> While this should not be a big deal for individuals it might place
> some extra burden on those maintaining binary distros like ms4w or
> fwtools
>
> 2) having refcounting enabled does not harm the cgi which should only
> experience a tini tiny (if any at all) performance drop because of the
> extra if and ++
>
> 3) we can always opt to introduce USE_MAPSCRIPT later
>
> 4) it simplifies the build process maintaining exactly like it's been until now
>
> 5) it simplifies the developer's life because of one less define to mantain
>
> I must say that after some reconsideration I think the USE_MAPSCRIPT
> is probably unnecessary, unless we can prove that the CGI is indeed
> slower when refcounting is in place, so I am voting +1 on the removal
> of USE_MAPSCRIPT.
>
> Note: the patch contains other useful stuff that I'll commit anyway
> very soon because it improves python/perl/ruby build process.
>
> Tamas: please fill the gaps if I forgot something...
>
> Regards,
> Umberto
>
>

This explanation was fairly exhaustive so I could mention additionally
only the buildbot configuration pains having a new mapscript specific
switch to handle, but it's not too substantial itself.

I add +1 to this conception. I think at this point we don't require to
have an escape path to 'revert RFC-24' in some cases. If the
implementation is correct it should not affect the other parties too
much.

Umberto,

How can we go towards the SWIG interface related changes. Is the core
implementation complete?

Best regards,

Tamas