Re: [Evolution-hackers] Removing libical fork, moving to new upstream?
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?
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?
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?
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?
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
