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

[Patrick Ohly <Patrick Ohly gmx de>]

On Tue, 2008-09-09 at 09:12 -0400, IGnatius T Foobar wrote:
> 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.

I agree.

> How would you feel about a global flag which tells libical how to 
> allocate memory?

The problem with that is that it is not possible to mix code which uses
the old and the new semantic. For example, a program or library which
uses libical directly, using the old semantic, couldn't be combined with
the Evolution libraries.

To let old and new code coexists I would suggest the following approach:
     1. The Evolution patch gets applied, making the core functions safe
        to use.
     2. The function implementations whose semantic has changed get
        renamed; I kind of like the _r suffix, but _alloc or _copy would
        also work.
     3. Under the old names small wrappers are added which establish the
        old behavior again by copying the string into the ring buffer
        and freeing the dynamically allocated one: this incurs some
        overhead, but usage of these versions of the calls is
        discouraged anyway. By using function attributes it would be
        possible to trigger deprecation warnings for code which still
        uses them.
     4. In the header file both variants are declared.
     5. In addition, ical.h also redefines the old names to the new
        names if the HANDLE_LIBICAL_MEMORY define is set: Evolution code
        already does that and therefore continues to work with such a
        modified upstream libical without source code changes.

I personally would prefer to avoid step 5 and rather do a search/replace
in Evolution, but Chenthill didn't like that.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/