[Evolution-hackers] error in generated vcalendar + error reading changed tasks/events

Armin Bauer armin.bauer@desscon.com
Wed, 09 Mar 2005 00:09:30 +0100
Previous message: [Evolution-hackers] error in generated vcalendar + error reading changed tasks/events
Next message: [Evolution-hackers] error in generated vcalendar + error reading changed tasks/events
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB358AEF1E1BF439ED748E5F8
Content-Type: multipart/mixed;
 boundary="------------080505080801060907030404"

This is a multi-part message in MIME format.
--------------080505080801060907030404
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit



JP Rosevear wrote:
> On Tue, 2005-03-08 at 21:35 +0100, Armin Bauer wrote:
>
>>JP Rosevear wrote:
>>
>>>On Tue, 2005-03-08 at 07:10 +0100, Armin Bauer wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>i discovered two bugs:
>>>>
>>>>The first one is in the way evo2 generates vcalendars:
>>>>
>>>>Categories get generated as:
>>>>CATEGORIES:Birthday\,Business
>>>>
>>>>but it should be (taken from http://www.ietf.org/rfc/rfc2445.txt):
>>>>CATEGORIES:MEETING,PROJECT
>>>
>>>
>>>It appears the rfc is contradicting itself in the examples, see 4.3.11.
>>>That shows the "text" grammar type to need escaping of commas and
>>>CATEGORIES is of this type, as well:
>>>
>>>   The "TEXT" property values may also contain special characters that
>>>   are used to signify delimiters, such as a COMMA character for lists
>>>   of values or a SEMICOLON character for structured values. In order to
>>>   support the inclusion of these special characters in "TEXT" property
>>>   values, they MUST be escaped with a BACKSLASH character. A BACKSLASH
>>>   character (US-ASCII decimal 92) in a "TEXT" property value MUST be
>>>   escaped with another BACKSLASH character. A COMMA character in a
>>>   "TEXT" property value MUST be escaped with a BACKSLASH character
>>>   (US-ASCII decimal 92). A SEMICOLON character in a "TEXT" property
>>>   value MUST be escaped with a BACKSLASH character (US-ASCII decimal
>>>   92).  However, a COLON character in a "TEXT" property value SHALL NOT
>>>   be escaped with a BACKSLASH character.Example: A multiple line value
>>>   of:
>>>
>>
>>actually its not:
>>
>>    Type name: CATEGORIES
>>
>>    Type purpose: To specify application category information about the
>>    vCard.
>
>
>>    Type encoding: 8bit
>>
>>    Type value: One or more text values separated by a COMMA character
>>    (ASCII decimal 44).
>
>
> Hmm, the above block is indeed a little confusing.  Let me state what
> i'm seeing:
>
> It says that "TEXT" property values may include a COMMA for a delimiter
> but that in order to include a COMMA in a "TEXT" property they must be
> escaped.  What they really want to say I guess is that they want to
> delimit blocks of "text", as defined in the abnf notation:      text
> = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR))
>
> with a comma, ie :text,text,text to make up a TEXT property value as a
> whole.
>
> Anyhow, I think whats really happening is that Evolution wants to use
> the CATEGORIES as a whole single string and breaks it up in the UI
> itself.  The \, means we are treating the categories as a single block
> rather a delimited list, that is valid icalendar, if a bit unusual.
>

So, judging from your answer, that you are not going to change this?

>
>>    Type example:
>>
>>         CATEGORIES:TRAVEL AGENT
>>
>>         CATEGORIES:INTERNET,IETF,INDUSTRY,INFORMATION TECHNOLOGY
>>
>>so this would be valid: sometext\,,somemoretext
>>
>>i know that the standard is just plain stupid at this point since the
>>categories is the only occasion they are using a comma
>>
>>and besides... even the evolution2 vcard parser is expecting the
>>categories with an unescaped comma :)
>>
>>
>>>
>>>>The second one is that when i add several tasks/events, request them via
>>>>e_cal_get_changes, delete all of them and request again using
>>>>e_cal_get_changes the returned GList will contain more items than delete
>>>>d and the additional items look like random memory locations. I attached
>>>>the code that produces this result. I took a look at the bug database
>>>>and there are quite some bugs which reporting crashing etc when deleting
>>>>tasks/events, so maybe this is related.
>>>
>>>
>>>Probably unrelated, but it might help against some pilot bugs.  What is
>>>the exactly version you are coding against?
>>
>>ii  evolution      2.0.4-0.1      The groupware suite
>>ii  evolution-data 1.0.4-0.1      evolution database backend server
>>
>>entry 20050308T203113Z-6966-1000-6736-0@azrael
>>entry 20050308T203113Z-6966-1000-6736-1@azrael
>>entry 20050308T203002Z-6781-1000-1-1@azrael
>>entry 20050308T203113Z-6966-1000-6736-2@azrael
>>entry 20050308T203002Z-6781-1000-1-2@azrael
>>entry 20050307T183359Z-32171-1000-1-42@azrael
>>
>>Note that i deleted 3 tasks (the ones with *1000-1*)
>
>
> Have you looked at the .xml file on disk to see if thats being updated
> properly?

Yes. i attached the ics and .db files after the first sync (after i
added 3 tasks) and after the second one (with the deletion). Nothing
suspicious...

But there seems to be another bug: take a look at before.ics. there are
errors in there which i guess is not correct. (but these errors are not
the root of the problem, i checked this)

>
> -JP

--------------080505080801060907030404
Content-Type: text/calendar;
 name="after.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="after.ics"

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Olson_20011030_5/Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
END:VCALENDAR

--------------080505080801060907030404
Content-Type: text/xml;
 name="after.ics-evo-kde.db"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="after.ics-evo-kde.db"

<?xml version="1.0" encoding="UTF-8"?>
<xmlhash/>

--------------080505080801060907030404
Content-Type: text/calendar;
 name="before.ics"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="before.ics"

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:/softwarestudio.org/Olson_20011030_5/Europe/Berlin
X-LIC-LOCATION:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=3
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=-1SU;BYMONTH=10
END:STANDARD
END:VTIMEZONE
BEGIN:VTODO
UID:20050308T225333Z-7732-1000-1-6@azrael
DTSTAMP:20050308T225333Z
SUMMARY:1
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for STATUS
 property. Removing entire property:
PRIORITY:0
CREATED:20050308T225333
LAST-MODIFIED:20050308T225333
END:VTODO
BEGIN:VTODO
UID:20050308T225333Z-7732-1000-1-7@azrael
DTSTAMP:20050308T225333Z
SUMMARY:2
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for STATUS
 property. Removing entire property:
PRIORITY:0
CREATED:20050308T225333
LAST-MODIFIED:20050308T225333
END:VTODO
BEGIN:VTODO
UID:20050308T225333Z-7732-1000-1-8@azrael
DTSTAMP:20050308T225333Z
SUMMARY:3
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for STATUS
 property. Removing entire property:
PRIORITY:0
CREATED:20050308T225333
LAST-MODIFIED:20050308T225333
END:VTODO
END:VCALENDAR

--------------080505080801060907030404
Content-Type: text/xml;
 name="before.ics-evo-kde.db"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="before.ics-evo-kde.db"

<?xml version="1.0" encoding="UTF-8"?>
<xmlhash><object uid="20050308T225333Z-7732-1000-1-8@azrael">BEGIN:VTODO
UID:20050308T225333Z-7732-1000-1-8@azrael
DTSTAMP:20050308T225333Z
SUMMARY:3
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for STATUS
 property. Removing entire property:
PRIORITY:0
CREATED:20050308T225333
LAST-MODIFIED:20050308T225333
END:VTODO
</object><object uid="20050308T225333Z-7732-1000-1-6@azrael">BEGIN:VTODO
UID:20050308T225333Z-7732-1000-1-6@azrael
DTSTAMP:20050308T225333Z
SUMMARY:1
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for STATUS
 property. Removing entire property:
PRIORITY:0
CREATED:20050308T225333
LAST-MODIFIED:20050308T225333
END:VTODO
</object><object uid="20050308T225333Z-7732-1000-1-7@azrael">BEGIN:VTODO
UID:20050308T225333Z-7732-1000-1-7@azrael
DTSTAMP:20050308T225333Z
SUMMARY:2
X-LIC-ERROR;X-LIC-ERRORTYPE=VALUE-PARSE-ERROR:No value for STATUS
 property. Removing entire property:
PRIORITY:0
CREATED:20050308T225333
LAST-MODIFIED:20050308T225333
END:VTODO
</object></xmlhash>

--------------080505080801060907030404--

--------------enigB358AEF1E1BF439ED748E5F8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFCLjCqq9z7v9k9UakRAitpAKCdvbs4N0Mc1rxQee/Wh8mQtfwgwACgnQra
6nxWRubzJfazgU5lI6amXS8=
=Vnq5
-----END PGP SIGNATURE-----

--------------enigB358AEF1E1BF439ED748E5F8--
Previous message: [Evolution-hackers] error in generated vcalendar + error reading changed tasks/events
Next message: [Evolution-hackers] error in generated vcalendar + error reading changed tasks/events
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]