On Tue, 2008-09-09 at 18:00 +0200, Patrick Ohly wrote:
On Tue, 2008-09-09 at 09:12 -0400, IGnatius T Foobar 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.
When I started writing the patch, since only the gnome packages which
depend on libecal are going be affected. I thought of incorporating
changes in all other modules myself since it was just to grep all the
apis and free the returned memory.
So I had a thinking that all the downstream projects would be ready to
change their code during a release time since stability is an issue and
change can be done fast. But if it was not the case and might result in
forking again, the only solution which I too see is create a new set of
API's which uses the new memory allocation.
How would you feel about a global flag which tells libical how to
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.
Yes right. Its not possible to have the old semantic with changed memory
To let old and new code coexists I would suggest the following approach:
1. The Evolution patch gets applied, making the core functions safe
2. The function implementations whose semantic has changed get
renamed; I kind of like the _r suffix, but _alloc or _copy would
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
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.
Since we do really want to remove the fork and pick up packages from
upstream, I can change the apis in evolution related packages if a new
set of apis with some suffix is provided from libical upstream.
The old patch is attached with bug 516408. You can find the patches at,
Evolution-hackers mailing list