Re: [Evolution-hackers] Removing libical fork, moving to new upstream?

["IGnatius T Foobar" <ajc citadel org>]

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