SWIG mapscript critical problems!!!

[Umberto Nicoletti]

Tamas,

On 6/20/06, Tamas Szekeres <szekerest at gmail.com> wrote:
> Umberto,
>
> All of the problems i have mentioned are properly identified and can
> be handled and no further investigations should be made.
>
> 1. The first one is the constructors of layerObj, classObj, and
> styleObj have already fixed for C# upon a previous user request. This
> solution could be made for the other bindings as well. See csmodule.i
> for more details. Despite of this fix reported as working i would
> prefer a safer and more clear approach if we would like to create an
> object and immediately add it to a parent like:
>
> mapObj map = new mapObj("mymap.map");
> layerObj newlayer = map.AddNewLayer();
>
> Objects returned are properly "disowned" by SWIG and the finalization
> of newlayer will not destroy the native memory referenced by the
> object. I consider these members are writable is not intentional.
> (members are exposed as writable by default).
>

This solution implies an API change which I don't favour. I like
better the solution you have already implemented in csmodule.i but it
needs to be extended to other languages and to other functions like
insertClass, setMetadata, etc.
Btw have you seen how the ruby people are doing it?
http://www.swig.org/Doc1.3/Ruby.html#Ruby_nn57

> 2. The other problem is that mapscript is exposing some object members
> as writable that theoretically should not be writable. (See my
> previous post)
> For example layerObj.map is handled internally and is solely for
> getting the reference of the parent object.

In Java you can't set the map reference, only get it.

> layerObj.metadata is a hashtable which is already created by
> initlayer. Why should we expose this member as writable? Users should
> only add and remove elements on it.
>

Because not all mapscript objects are properly set up: for instance
webObj until recently did not have a constructor which invoked initWeb
so the metadata had to be set from Java. This can be solved of course,
but it would break backwards compatibility (API change).

I volunteer to write unit tests for Java and port your implementation
to Java once we agree on a solution.

Umberto

>
> I agree that these are not the only problems so further investigations
> should be made.
>
> Tamas
>
> PS: Did you step forward with the getFeature issue?
>
>
> 2006/6/20, Umberto Nicoletti <umberto.nicoletti at gmail.com>:
> > Tamas,
> > those problems do exist in Java Mapscript too (see Benedikt's earlier
> > post)  and I believe they exist in every mapscript with a gc.
> >
> > In my opinion we should distinguish two main common usage scenarios:
> >
> > 1) apps that reimplement the functionality of the mapserver cgi and
> > mainly display an existing map file
> > 2) apps that attempt to go beyond the basic and build maps, layers,
> > classes, etc at runtime
> >
> > In the first case Java, C# and probably other mapscripts are mature
> > enough to allow their use in production environment. Garbage
> > collection will work and no memory leaks occur.
> >
> > The latter case is where we are stuck at the moment as we're having a
> > real problem with memory management.
> > First of all I we should make end users aware of these issues by
> > keeping a 'mapscript state uf the union' page on mapserver web site
> > describing what is safeto do and what is not. This will create less
> > confusion and frustration among our users (and allows for RTFM replies
> > ;-)).
> > Then we should google the web to see how others are handling similar
> > problems and take inspiration from what we see. It also probably needs
> > an rfc of its own.
> >
> > Umberto
> >
> > On 6/16/06, Tamas Szekeres <szekerest at gmail.com> wrote:
> > > Developers,
> > >
> > > Along with the recent postings on the user's list some of the folks
> > > are complaining about funky
> > > segfaults, memory reference exceptions when using some of the mapscript objects.
> > >
> > > I have found the following problems and would like to know if these
> > > issues apply to the other languages or not.
> > >
> > > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1803
> > > http://mapserver.gis.umn.edu/bugs/show_bug.cgi?id=1743
> > >
> > > Best Regards,
> > >
> > > Tamas
> > >
> >
>