[RFC-24] Updated public draft

[Tamas Szekeres]

>
> Tamas, doesn't this look like my previous proposal (keep references in
> the mapscript wrapper classes and don't touch the C layer)?
>
>
> A general consideration, please don't take it as rudeness I am just
> getting straight to the core of the issue at hand:
>
> at this point I am not quite sure about the road the want to take. My
> first proposal was in my opinion easy doable, but it required a
> separate implementation for every mapscript.
> Because of this I was asked for something more portable across
> mapscripts and maybe even php so I came up with the second release of
> RFC-24.
> And now, again, it seems like we are going back to a slightly
> different version of the first rfc24.

Umberto,

I can see your raising, but none of us has a supernatural power enough
to propose the optimal solution at the first sight. Having more and
more information about the code structure and the philosophy behind
the implementation it's not a big shame to select and reintroduce a
solution have been rejected before. However - in fact - we might get
back to that variant in a higher level so the line of the development
can be recognized unambiguously.

Generally speaking my primary objection is to achieve the desired
functionality with the smallest amount of code changes as possible. In
my experience applying a big change in the philosophy might induce a
lot of additional working and testing unexpectedly to achieve the same
degree of reliability as before. If you can propose a feasible and not
too complicated solution for fixing the problem let's talk about it.
However at this point I have some doubts that it could be done easily.

In the meantime I've spent 3 days implementing a reference counting
approach at the C side by not altering current the memory allocation
model. That solution aimed to consider how the various objects are
related to each other in regard to the memory management. On one hand
it was not difficult to create a memory context structure for the
'root object' and implement the proper AddRef/Release operation on the
various objects without requiring much amount of coding. However my
penknife has broken in tracking down every object allocations and
initializing the proper memory context for every newly created object.
Sometimes we have a definite initXXX function but in many cases that
allocation happens casually and the parent/owner context cannot be
obtained without writing of additional code. To the end of the day I
could recognize that implementing this kind of changes is much more
difficult as expected and cannot be accepted by any TSC easily.


>
> Now, I want to clarify that I am doing this in my spare time and with
> little to no funding so I can tolerate one or two of these U-turns,
> but I can't simply afford to go on forever discussing and modifying
> documents. Also please understand that I am NOT saying this discussion
> is useless or annoying, I highly value the exchange of ideas with
> fellow programmers (especially if talented like most of you), as long
> as they become real sooner or after.
>

You surely wanted to solve this problem for all of the bindings
uniquely mainly at the target language side. At this point I can't see
any objections having customized solutions for each of the languages ,
by keeping the same interface API of course. I consider this part of
the activity is not a subject of voting since every language maintaier
is responsible for the problems of their own binding. The owner of
that component can decide which problem is substantial and what is the
optimal fix for it. So for the C# part I volunteer to implement my
in-house solution to protect against 2.2 and 2.3.

You would rather have to deal with the changes affecting the common
parts (apparently for 2.1)  that are required to be discussed in a
wider scope and should be proposed for voting potentially.

> So my proposal is that I attach patches to the tracker bug and rather
> discuss on those than on this rfc. This would also have the benefit
> that once we vote and if the rfc gets a positive feedback the
> implementation is already adavanced to the point that you can already
> see something working.

OK.

Best regards,

Tamas