Re: [evolution-patches] [Fwd: eds/calendar, crash import fix]
- From: Rodrigo Moya <rodrigo novell com>
- To: Not Zed <notzed ximian com>
- Cc: JP Rosevear <jpr novell com>, Evolution Patches <evolution-patches lists ximian com>
- Subject: Re: [evolution-patches] [Fwd: eds/calendar, crash import fix]
- Date: Tue, 03 Aug 2004 13:41:14 +0200
On Tue, 2004-08-03 at 13:56 +0800, Not Zed wrote:
> On Tue, 2004-08-03 at 01:25 -0400, JP Rosevear wrote:
> > On Mon, 2004-08-02 at 14:45 +0800, Not Zed wrote:
> > > Email message/mailbox attachment, "Forwarded message - eds/calendar,
> > > crash import fix"
> > > On Mon, 2004-08-02 at 14:45 +0800, Not Zed wrote:
> > > >
> > > > while looking at another bug i hit this crash on the first calendar
> > > > list i tried to import i found on a web page.
> > > >
> > > > it still doesn't import (or at least, if it does i can't find where
> > > > it went), but at least e-d-s doesn't go into an infinite crash-loop
> > > > trying to import a calendar file.
> > > >
> > > > so, no idea if this is even closely related ot the right fix.
> >
> > If comp_uid is NULL after trying to generate it, we should still bail
> > out with an error, invalid object or something. We need the uid (and
> > the spec demands it).
> Ok, I wasn't sure on that.
>
> But these external calendars seem to have this quite often, i just
> wonder if it will be needed for interoperability. It seems odd to me
> that the importer isn't doing some pre-processing to cope with this
> though, rather than opening the data directly in the backend code.
>
yes, the importer code could deal with this, but the **importer code**,
not the backend. So I would add that code to the importers code rather
than to the backend.
--
Rodrigo Moya <rodrigo novell com>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]