Chenthill wrote:
So it is better to inform all the stake holders about the change and let
them depend on the library versions to decide whether to free the memory
or not if they have a need to depend on the older versions of libical. I
think no one deny to make the necessary changes knowing that the old API
is not very stable.

Atleast once I noticed the problem. I made this patch and made all the
changes required in evolution, evolution-exchange and
evolution-data-server. I would not really like to change them again with
new APIS :)
Although I agree that the new memory model is a vast improvement over the existing one, I think you may be underestimating the potential effects of telling dozens of downstream projects that they will have to rewrite their code *right* *now* in order to continue using libical. Many will respond by forking, or staying forked, which as I mentioned earlier is exactly the opposite of what we are trying to accomplish.

How would you feel about a global flag which tells libical how to allocate memory? Surely you wouldn't mind adding one line of code during an initialization phase that tells libical "caller accepts the responsibility to free all returned strings" ?? (The ring buffer memory model, inferior as it may be, must still be the default in order to run existing code unmodified.)

If this is acceptable, then would someone please point us to a patch which implements the memory management changes, and we'll apply an enhanced version of it with user-selectable memory allocation model added in.

 -- Art
Evolution-hackers mailing list

Reply via email to