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