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

2008-10-10 Thread IGnatius T Foobar
No worries, we're not on a strict release schedule.   We can do point 
releases at any time if you find that something needs to be updated.


Thanks for your continued involvement.  We're really looking forward to 
the final outcome.


 -- Art

Chenthill wrote:

I was not able to try the upstream libical yet. I am right now packed
with some other work, so I will try to get this done as soon as
possible.  Suddenly the weekends have gone out of my hands as I have to
move out of station to places that do not have internet connectivity.
Either me or suman will make the changes and get the work done for
2.25.1 if the time is sufficient to get libical as a external dependency
for GNOME 2.25.1. We would test the library and let you know before oct
17th.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-10-06 Thread Chenthill
I was not able to try the upstream libical yet. I am right now packed
with some other work, so I will try to get this done as soon as
possible.  Suddenly the weekends have gone out of my hands as I have to
move out of station to places that do not have internet connectivity.
Either me or suman will make the changes and get the work done for
2.25.1 if the time is sufficient to get libical as a external dependency
for GNOME 2.25.1. We would test the library and let you know before oct
17th.

thanks, Chenthill.
On Fri, 2008-09-19 at 14:41 +0530, Chenthill wrote:
 On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote:
   I have applied Chenthill's memory management patches (only to the 
   'libical' directory and to the examples -- still have to do the 
   'libicalcap' and 'libicalss' directories) using function names ending in 
   _r.  
   IMHO, HANDLE_LIBICAL_MEMORY can be removed.
 
  
  Ok folks, it's done ...
  
  The remaining portions of libical (libicalcap and libicalss) have been 
  converted to the _r API.   (The test suite still uses the old API and 
  will continue to do so for a while.)
  
  Now is the time for Evolution code to be updated to use the new calling 
  syntax.
  
  Is there anything we can do to facilitate this, or should we just hang 
  out and wait for you folks to kick the tires on the new library?  Let me 
  know...
 I will make the changes and test it over this weekend.
 
 thanks, Chenthill.
 
 ___
 Evolution-hackers mailing list
 Evolution-hackers@gnome.org
 http://mail.gnome.org/mailman/listinfo/evolution-hackers

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-09-23 Thread IGnatius T Foobar


I have applied Chenthill's memory management patches (only to the 
'libical' directory and to the examples -- still have to do the 
'libicalcap' and 'libicalss' directories) using function names ending in 
_r.  

IMHO, HANDLE_LIBICAL_MEMORY can be removed.
  


Ok folks, it's done ...

The remaining portions of libical (libicalcap and libicalss) have been 
converted to the _r API.   (The test suite still uses the old API and 
will continue to do so for a while.)


Now is the time for Evolution code to be updated to use the new calling 
syntax.


Is there anything we can do to facilitate this, or should we just hang 
out and wait for you folks to kick the tires on the new library?  Let me 
know...


  -- Art

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-09-19 Thread Chenthill
On Thu, 2008-09-18 at 22:52 -0400, IGnatius T Foobar wrote:
  I have applied Chenthill's memory management patches (only to the 
  'libical' directory and to the examples -- still have to do the 
  'libicalcap' and 'libicalss' directories) using function names ending in 
  _r.  
  IMHO, HANDLE_LIBICAL_MEMORY can be removed.

 
 Ok folks, it's done ...
 
 The remaining portions of libical (libicalcap and libicalss) have been 
 converted to the _r API.   (The test suite still uses the old API and 
 will continue to do so for a while.)
 
 Now is the time for Evolution code to be updated to use the new calling 
 syntax.
 
 Is there anything we can do to facilitate this, or should we just hang 
 out and wait for you folks to kick the tires on the new library?  Let me 
 know...
I will make the changes and test it over this weekend.

thanks, Chenthill.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-09-17 Thread IGnatius T Foobar



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.
  
Many of you have probably already read this on the libical mailing list, 
but just in case:


I have applied Chenthill's memory management patches (only to the 
'libical' directory and to the examples -- still have to do the 
'libicalcap' and 'libicalss' directories) using function names ending in 
_r.  For example, icalcomponent_as_ical_string() is now simply a 
wrapper around icalcomponent_as_ical_string_r() which places the new 
string buffer on the ring before returning it to the caller.  The 
functions whose names end in _r have had Chenthill's memory management 
patches applied to them.


Do we still need to add the HANDLE_LIBICAL_MEMORY hack to make the old 
function names act like the new ones?  Chenthill's most recent message 
(quoted above) seems to imply that the Evolution team is willing to move 
to the new function names.  Let me know.


  -- Art

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-09-10 Thread Chenthill
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:
  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.
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 
  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.

Yes right. Its not possible to have the old semantic with changed memory
allocation. 
 
 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.
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,

http://svn.gnome.org/viewvc/libical?view=revisionrevision=633 
and 
http://svn.gnome.org/viewvc/libical?view=revisionrevision=637


thanks, Chenthill.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-09-10 Thread IGnatius T Foobar

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


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

2008-09-09 Thread Chenthill


On Mon, 2008-09-08 at 23:55 -0400, IGnatius T Foobar wrote:
 Patrick Ohly wrote:
  In the upstream libical certain functions return char * pointers into
  memory stored in ring buffers. The caller must not free those pointers.
  The drawback is that the life time of those strings is not predictable.
 
  In the current Evolution libical, those same functions (not renamed!)
  return copies of the string which the caller has to free. Code which was
  written using the old semantic of the calls will leak memory. Code
  adapted to the new semantic (like Evolution) will crash when combined
  with the upstream libical without the same patch.

 Ok, I definitely see the benefit there.   This is similar to POSIX calls 
 which now offer alternative versions (usually with _r appended to the 
 name) that don't use a static buffer or a ring buffer, in order to be 
 reentrant?
  If all users of the upstream libical are willing to adapt their code,
  then the best solution would be to simply import the Evolution patch
  into upstream.

 As much as I'd like to see that happen, I don't think it's realistic.  
 libical is used by dozens of downstream projects, and a sudden forced 
 API change is likely to encourage them to fork (or stay forked, if 
 they've already done so) -- exactly the opposite of the end we are 
 trying to achieve!
  If there is resistance against that, then we could provide two versions
  of each of these API calls: one with the old name and old behavior and
  one with the new behavior and a name suffix. 
 That seems more realistic.  The alternative might be to offer a global 
 flag that tells libical to behave one way or the other?  (I think 
 something like that was suggested at some point.)
 
 While I definitely think the new method of memory allocation makes far 
 more sense (we'll definitely use it in Citadel, as all of our code is 
 multithreaded) -- expecting the entire community to perform a flag day 
 API change in lockstep is likely to cause confusion and delay.   If we 
 pursued either the alternate function names or the global flag, is there 
 likely to be any pushback from the Evolution team?
I do not feel having alternate function names would be a better
solution.

Consider the following API which remains the same before and after the
memory fixes,
char * icalcomponent_as_ical_string (icalcomponent *icomp);

The returned memory from this API was internally handled by libical
before and now its given to the caller. Though the return type gives an
indication that the memory is owned by caller, it was not the case. So
having a new API for this and changing the behavior does not look to be
a good solution since the underlying memory allocation had to be
changed.

Similarly even with other APIs which return const char* values, the
memory can be overwritten at any time. While removing the ring buffer
return type's of all the APIs had to be changed from const char * to
char *. Is it really worth it to have the old unstable APIs which can
crash the application randomly ? My answer would be NO.

This is not just a problem with multi-threaded programs. The crash could
happen once the ring buffer gets full and starts overwriting the used
memory.

Since we statically link to libical and expose it via libecal, we have
updated the library versions of libecal. We have an additional flag
check (hack) also for it now with a warning as in
http://bugzilla.gnome.org/show_bug.cgi?id=528986 .


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 :)


thanks, Chenthill.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-09-09 Thread Patrick Ohly
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


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

2008-09-08 Thread Chenthill
On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote:
 Hello!
 
 http://sourceforge.net/projects/freeassociation/ has released 0.32 of
 libical on 2008-09-01. The KDE-PIM team has switched to that code for
 KDE 4.2.
 
 On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:
  On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: 
   I discovered last week that there is an attempt to resurrect libical
   from non-maintainership, merge all of the patches from various forks,
   and start making sane releases again[1].  Are the evolution team as
   whole interested in merging their changes to libical upstream and
   depending on it to be installed when a release is made with all of the
   relevant changes?  libical isn't exactly a small library, and statically
   linking it is a waste of memory for everyone.
 
  I vaguely recall the biggest diff being timezone handling.
 
 Not sure about that. They have merged the system timezone database
 conversion code, if that's what you mean. Unfortunately they missed the
 recent bug fixes required for that code to handle the upcoming
 summer-winter time transition. We really should have been more active
 with keeping them informed about Evolution-libical changes. I have
 alerted them and the KDE-PIM team of the problem.
 
 However, they haven't included the modified memory handling. Considering
 that this breaks the user space API merging it might be a hard sell.
 
   I'll happily start working on extracting the changes to EDS and pushing
   them into the new libical repository, if the Evolution team as a whole
   agrees that the fork of libical will be dropped.
 
 +1
+1 from my side too. We were discussing about this at
http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes
to be merged upstream. We wanted to get this done for 2.26.

thanks, Chenthill.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-09-08 Thread Chenthill
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote:
 Chenthill wrote: 
  On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote:

   Hello!
   
   http://sourceforge.net/projects/freeassociation/ has released 0.32 of
   libical on 2008-09-01. The KDE-PIM team has switched to that code for
   KDE 4.2.
   
   On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:
   
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: 
  
 I discovered last week that there is an attempt to resurrect libical
 from non-maintainership, merge all of the patches from various forks,
 and start making sane releases again[1].  Are the evolution team as
 whole interested in merging their changes to libical upstream and
 depending on it to be installed when a release is made with all of the
 relevant changes?  libical isn't exactly a small library, and 
 statically
 linking it is a waste of memory for everyone.
 
I vaguely recall the biggest diff being timezone handling.
  
   Not sure about that. They have merged the system timezone database
   conversion code, if that's what you mean. Unfortunately they missed the
   recent bug fixes required for that code to handle the upcoming
   summer-winter time transition. We really should have been more active
   with keeping them informed about Evolution-libical changes. I have
   alerted them and the KDE-PIM team of the problem.
   
   However, they haven't included the modified memory handling. Considering
   that this breaks the user space API merging it might be a hard sell.
   
   
 I'll happily start working on extracting the changes to EDS and 
 pushing
 them into the new libical repository, if the Evolution team as a whole
 agrees that the fork of libical will be dropped.
 
   +1
   
  +1 from my side too. We were discussing about this at
  http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes
  to be merged upstream. We wanted to get this done for 2.26.
  
  thanks, Chenthill
 In what way does it break the userspace API?   Is it possible that the
 API could be extended in such a way that memory handling depends upon
 how it's called?
All the information/discussion about this is available at,
http://bugzilla.gnome.org/show_bug.cgi?id=516408
and
http://bugzilla.gnome.org/show_bug.cgi?id=528986
 
 We would *really* like to get everyone merged and re-unify this
 library once and for all.  Everyone would benefit.
We provide our support too to get this done!!


thanks, Chenthill.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-09-08 Thread Patrick Ohly
On Mon, 2008-09-08 at 12:16 -0400, IGnatius T Foobar wrote:
 In what way does it break the userspace API?   Is it possible that the
 API could be extended in such a way that memory handling depends upon
 how it's called?

Chenthill already provided the relevant links:
http://bugzilla.gnome.org/show_bug.cgi?id=516408
http://bugzilla.gnome.org/show_bug.cgi?id=528986

For the sake of discussion let me summarize how the API has changed,
then suggest ways how that could be dealt with.

In the upstream libical certain functions return char * pointers into
memory stored in ring buffers. The caller must not free those pointers.
The drawback is that the life time of those strings is not predictable.

In the current Evolution libical, those same functions (not renamed!)
return copies of the string which the caller has to free. Code which was
written using the old semantic of the calls will leak memory. Code
adapted to the new semantic (like Evolution) will crash when combined
with the upstream libical without the same patch.

There are defines in the Evolution libical header which can be used to
detect what the memory handling is, so code can be written so that it
works with both the old and the new semantic. SyncEvolution goes one
step further and also does a runtime check, so the same binary works
with both an old and a new Evolution release.

If all users of the upstream libical are willing to adapt their code,
then the best solution would be to simply import the Evolution patch
into upstream.

If there is resistance against that, then we could provide two versions
of each of these API calls: one with the old name and old behavior and
one with the new behavior and a name suffix. Evolution then has to be
patched to use the new calls, which can be done either with a global
search/replace or via defines (ugly!). SyncEvolution would work fine
without code changes, it'll simply fall back to not freeing the strings.

-- 
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


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

2008-09-08 Thread IGnatius T Foobar




Chenthill wrote:

  On Sat, 2008-09-06 at 11:02 +0200, Patrick Ohly wrote:
  
  
Hello!

http://sourceforge.net/projects/freeassociation/ has released 0.32 of
libical on 2008-09-01. The KDE-PIM team has switched to that code for
KDE 4.2.

On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:


  On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote: 
  
  
I discovered last week that there is an attempt to resurrect libical
from non-maintainership, merge all of the patches from various forks,
and start making sane releases again[1].  Are the evolution team as
whole interested in merging their changes to libical upstream and
depending on it to be installed when a release is made with all of the
relevant changes?  libical isn't exactly a small library, and statically
linking it is a waste of memory for everyone.

  
  I vaguely recall the biggest diff being timezone handling.
  

Not sure about that. They have merged the "system timezone database
conversion" code, if that's what you mean. Unfortunately they missed the
recent bug fixes required for that code to handle the upcoming
summer-winter time transition. We really should have been more active
with keeping them informed about Evolution-libical changes. I have
alerted them and the KDE-PIM team of the problem.

However, they haven't included the modified memory handling. Considering
that this breaks the user space API merging it might be a hard sell.



  
I'll happily start working on extracting the changes to EDS and pushing
them into the new libical repository, if the Evolution team as a whole
agrees that the fork of libical will be dropped.

  

+1

  
  +1 from my side too. We were discussing about this at
http://bugzilla.gnome.org/show_bug.cgi?id=541209 and wanted the changes
to be merged upstream. We wanted to get this done for 2.26.

thanks, Chenthill

In what way does it break the userspace API? Is it possible that the
API could be extended in such a way that memory handling depends upon
how it's called?

We would *really* like to get everyone merged and re-unify this library
once and for all. Everyone would benefit.

 -- Art



___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2008-09-08 Thread IGnatius T Foobar

Patrick Ohly wrote:

In the upstream libical certain functions return char * pointers into
memory stored in ring buffers. The caller must not free those pointers.
The drawback is that the life time of those strings is not predictable.

In the current Evolution libical, those same functions (not renamed!)
return copies of the string which the caller has to free. Code which was
written using the old semantic of the calls will leak memory. Code
adapted to the new semantic (like Evolution) will crash when combined
with the upstream libical without the same patch.
  
Ok, I definitely see the benefit there.   This is similar to POSIX calls 
which now offer alternative versions (usually with _r appended to the 
name) that don't use a static buffer or a ring buffer, in order to be 
reentrant?

If all users of the upstream libical are willing to adapt their code,
then the best solution would be to simply import the Evolution patch
into upstream.
  
As much as I'd like to see that happen, I don't think it's realistic.  
libical is used by dozens of downstream projects, and a sudden forced 
API change is likely to encourage them to fork (or stay forked, if 
they've already done so) -- exactly the opposite of the end we are 
trying to achieve!

If there is resistance against that, then we could provide two versions
of each of these API calls: one with the old name and old behavior and
one with the new behavior and a name suffix. 
That seems more realistic.  The alternative might be to offer a global 
flag that tells libical to behave one way or the other?  (I think 
something like that was suggested at some point.)


While I definitely think the new method of memory allocation makes far 
more sense (we'll definitely use it in Citadel, as all of our code is 
multithreaded) -- expecting the entire community to perform a flag day 
API change in lockstep is likely to cause confusion and delay.   If we 
pursued either the alternate function names or the global flag, is there 
likely to be any pushback from the Evolution team?


  -- Art

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2007-05-21 Thread Srinivasa Ragavan
On Sun, 2007-05-20 at 21:49 +, JP Rosevear wrote:
 On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote:
  Hi,
  
  I discovered last week that there is an attempt to resurrect libical
  from non-maintainership, merge all of the patches from various forks,
  and start making sane releases again[1].  Are the evolution team as
  whole interested in merging their changes to libical upstream and
  depending on it to be installed when a release is made with all of the
  relevant changes?  libical isn't exactly a small library, and statically
  linking it is a waste of memory for everyone.
 
 I vaguely recall the biggest diff being timezone handling.
 
  I'll happily start working on extracting the changes to EDS and pushing
  them into the new libical repository, if the Evolution team as a whole
  agrees that the fork of libical will be dropped.
 
 I'd suggested waiting to see a pattern of stable releases before moving
 externally, but getting the patches upstream would be good.

Sounds very reasonable to me. 

-Srini.

 
 -JP

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2007-05-20 Thread Matthew Barnes
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote:
 I'll happily start working on extracting the changes to EDS and pushing
 them into the new libical repository, if the Evolution team as a whole
 agrees that the fork of libical will be dropped.

+1

Matthew Barnes

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2007-05-20 Thread JP Rosevear
On Sun, 2007-05-20 at 15:03 +0100, Ross Burton wrote:
 Hi,
 
 I discovered last week that there is an attempt to resurrect libical
 from non-maintainership, merge all of the patches from various forks,
 and start making sane releases again[1].  Are the evolution team as
 whole interested in merging their changes to libical upstream and
 depending on it to be installed when a release is made with all of the
 relevant changes?  libical isn't exactly a small library, and statically
 linking it is a waste of memory for everyone.

I vaguely recall the biggest diff being timezone handling.

 I'll happily start working on extracting the changes to EDS and pushing
 them into the new libical repository, if the Evolution team as a whole
 agrees that the fork of libical will be dropped.

I'd suggested waiting to see a pattern of stable releases before moving
externally, but getting the patches upstream would be good.

-JP
-- 
JP Rosevear [EMAIL PROTECTED]
Novell, Inc.

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers