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
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers