[Freeassociation-devel] Default value for ical_errors_are_fatal

[Chenthill]

Hi Patrick,
        The only concern we have at the moment is the stability. I heard
from suman, after testing with this ical_error_*fatal set there seems to
be a lot of crashers since evolution does not handle certain cases
properly. They need to be fixed, but since all the testing till now had
been done without this option set, we do not want to fiddle with the
stability by setting this option turned on now.  

   Till now all the applications which link to libecal use both libecal
(ECalComponent) and libical api's interchangeably as libecal does not
wrap all the functionality. Libical inside GNOME can only be built
inside EDS and so there can be a possibility that applications may link
to libecal and just use libical apis. In which case setting the variable
to 0 inside libecal may not suffice as we would now dynamically link to
libical. So this means we would need to set this option inside libecal
and also in external applications which uses libecal. 
   
   For the above reason, we were thinking if it can be set inside
libical through a configurable option it would be better. After fixing
the issues in packages which link to libecal, we will be happy to have
this option enabled. At the moment considering the effort available, we
may not be able to fix all the issues soon.


thanks, Chenthill.
On Tue, 2008-12-16 at 13:49 +0100, Patrick Ohly wrote:
> On Mon, 2008-12-15 at 20:38 +0530, Suman Manjunath wrote:
> > On Mon, Dec 15, 2008 at 20:11, Allen Winter <winter at kde.org> wrote:
> > > Except suppose another project (eg. KDE) want the opposite behavior?
> > > Then a distro will have to choose who best to support.  They won't
> > > provide  libical-barf and libical-nobarf packages.
> > >
> > > All those asserts were a pain to deal with -- no doubt about it.
> > > OTOH, we found real problems in our KDE code because of them.
> > 
> > It's good to know that bugs were fixed in your code. It may not be the
> > case with other projects. It certainly is not the case with evolution
> > and friends.
> 
> How do you know? Probably I'm missing something, but isn't the reason
> why Evolution needs the icalerror_errors_are_fatal to be off that it
> *does* trip up libical occasionally?
> 
> Are you saying that this is because of legimitate error cases (bad input
> data, etc.) and not because of bugs in Evolution? That is a pretty bold
> statement; it would be interesting to see what happens when running
> Evolution with icalerror_errors_are_fatal enabled.
> 
> > > So I'm more in favor of the applications dealing with it; either they
> > > fix their code or they need to set the global variable appropriately.
> > 
> > Like I mentioned, it's good to have the fatality in a developer
> > environment (which is why I proposed it be enabled by default), but
> > not in a shipped package. Maybe not yet.
> > 
> > The option of setting the variable at runtime is probably not a good
> > option EVER, for each process which depends libical needs to do it.
> > Every application that depends on a library that in-turn depends on
> > libical need to do 'em again.
> 
> The global option per se is problematic, because one part of a program
> might want it to be on and another, completely independent part which
> also uses libical wants it to be off. Not sure what can be done about
> it, given the current libical API. I don't think it matters much whether
> it is on or off by default.
> 
> Back to the Evolution context: why is it bad to set
> icalerror_errors_are_fatal to 0 when libecal is initialized? That
> ensures that it is off whenever Evolution or libecal apps are using
> libical, doesn't it?
> 
> If you are concerned that the initialization order might become relevant
> (app starts, sets icalerror_errors_are_fatal to 1, libecal resets it to
> 0), then you could declare a global variable of the same name with value
> 0 in libecal and not explicitly set it anywhere in libecal. Put the
> symbol in its own .o file and you are guaranteed to not have linking
> isues, even with static linking.
>