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
--
[EMAIL PROTECTED]
http://www.estamos.de/
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
