6.0.0-git
2019-03-21

[#1881] Support vCal/iCal 1.0/2.0 and differentiate between them
Summary Support vCal/iCal 1.0/2.0 and differentiate between them
Queue Horde Framework Packages
Type Bug
State Resolved
Priority 2. Medium
Owners chuck (at) horde (dot) org
Requester horde (at) eltofts (dot) homelinux (dot) com
Created 2005-04-28 (5075 days ago)
Due
Updated 2006-01-08 (4820 days ago)
Assigned 2005-12-28 (4831 days ago)
Resolved 2006-01-08 (4820 days ago)
Milestone
Patch No

History
2006-01-08 17:58:08 Chuck Hagenbuch Comment #11
State ⇒ Resolved
Reply to this comment
Resolving. Please comment if there are additional problems, and I'll 
re-open and address them.
2005-12-28 20:06:26 Chuck Hagenbuch Comment #10 Reply to this comment
If I'm not mistaken this ticket can be closed now. Anyone see anything 
I missed?
2005-12-28 19:58:02 kevin_myer (at) iu13 (dot) org Comment #9 Reply to this comment
Actually, I had tried this:



if (!preg_match('/(d|w|mp|md|ym|yd)(\d+)?(.*)/i', $rrule, $matches)) {



Seemed to work, but I'm not sure which is more efficient.  Your fix 
worked too.
2005-12-28 17:59:32 Jan Schneider Assigned to Chuck Hagenbuch
Taken from Horde DevelopersHorde Developers
State ⇒ Assigned
 
2005-12-28 16:36:04 kevin_myer (at) iu13 (dot) org Comment #7 Reply to this comment
I've taken a shot at this in HEAD. Please take a look.
Works very well for syncing events from Kronolith to the PDA, although 
admittedly not extensively tested (2.0 -> 1.0 conversion).  I'm having 
trouble going the other way though, with a recurring event created on 
the Palm.  I think the regexp is matching too much, which never causes 
the case statement to fire on the proper matching rule.  Changing the 
case statement in _readRRule10 to match W1 causes the event to get 
translated properly.



Sample event:

BEGIN:VCALENDAR^M

VERSION:1.0^M

BEGIN:VEVENT^M

SUMMARY:Test^M

CLASS:PUBLIC^M

DESCRIPTION:^M

DTSTART:20051228T080000^M

DTEND:20051228T090000^M

RRULE:W1 WE #0^M

END:VEVENT^M

END:VCALENDAR




2005-12-26 00:32:27 Chuck Hagenbuch Comment #6
State ⇒ Feedback
Reply to this comment
I've taken a shot at this in HEAD. Please take a look.
2005-12-11 17:31:35 Chuck Hagenbuch Comment #5 Reply to this comment
I would very much prefer it if the iCalendar library took a version 
number as a parameter and behaved appropriately based on that. Default 
of 2.0 sounds right to me. And yes, the synthesis drivers could 
request 1.0 when exporting (would have to be passed to the args to the 
calendar/export call, but that seems reasonable), and on import, we 
should auto-detect if at all possible and behave accordingly.
2005-12-09 03:05:48 kevin_myer (at) iu13 (dot) org Comment #4 Reply to this comment
I've been dabbling with this for a bit the past few weeks, because 
lack of Palm sync support for recurring events is held up by this.



I've found some other code that does this, to varying degrees:



http://www.simondobson.org/downloads/files/ical2vcal

http://websvn.kde.org/branches/KDE/3.5/kdepim/korganizer/ical2vcal.in?rev=438982&view=markup

and the function format_vcal($event) in:

http://cvs.sourceforge.net/viewcvs.py/webcalendar/webcalendar/includes/xcal.php?rev=1.10&view=markup



Now my initial approach was to work this into the Synthesis Device 
code for SyncML but in thinking about that approach, it seems like it 
might make sense to have it in the iCalendar framework code.  My 
thinking is a pair of functions (with the original names of ical2vcal 
and vcal2ical) would take an iCalendar object, and modify the object 
to make it v1.0 or v2.0 compatible.  The Synthsis SyncML Device code 
could call those functions, but they could also be used anywhere else 
(like importing old vCal data).  Or for that matter, have the 
iCalendar object automatically handle conversion, based on version 
requested, with a default of iCal (v2.0).



Any other suggestions or better ideas how to handle this?
2005-07-01 19:57:19 Chuck Hagenbuch Comment #3 Reply to this comment
just in case, here's the full context this came from initially (a 
response to someone from the Synthesis folks):







The problem is that the horde server for some unknown reason now sends

calendar entries in an invalid vCalendar format (a mixture of vCalendar

1.0 and iCalendar 2.0). This is clearly a bug in the server, and has

nothing to do with the version v2.1 vs. v2.5 of our client.



In Detail:



The server sends entries with MIME type "text/x-vcalendar", which would

indicate vCalendar v1.0.



However, the actual data set is someting like:



BEGIN:VCALENDAR

VERSION:2.0

PRODID:-//The Horde Project//Horde_iCalendar Library //EN

METHOD:PUBLISH

BEGIN:VEVENT

DTSTART:20050429T100000Z

DTEND:20050429T110000Z

DTSTAMP:20050426T004536Z

SUMMARY;ENCODING=QUOTED-PRINTABLE;CHARSET=UTF-8:=

Servers de Poort

TRANSP:OPAQUE

ORGANIZER;CN=Joeri Pronk:MAILTO:joeri@joeri.nu

CATEGORIES:Esprit

END:VEVENT

END:VCALENDAR



The second line (VERSION:2.0) identifies this as a iCalendar 2.0 entry.

However, it is NOT iCalendar 2.0 compatible as the CHARSET attribute is

not allowed in iCalendar 2.0.



If the VERSION line is fixed to read VERSION:1.0, it will be conformant

and will work with our client.
2005-05-23 14:11:59 Chuck Hagenbuch Summary ⇒ Support vCal/iCal 1.0/2.0 and differentiate between them
 
2005-05-23 13:48:06 kevin_myer (at) iu13 (dot) org Comment #2 Reply to this comment
Just wanted to note that another area this crops up is when trying to 
import vCal data that has been exported from Palm Desktop.  Two 
problems occur:



1)  Some events cause the import process to totally bomb.  I need to 
isolate the events, since this user's data stretches back to 2001, so 
I'm not sure which events are causing problems (and this may not even 
be related to recurrence - just bad Palm data)



2)  Events with recurrence only show the initial event on the first 
day, as noted on the original filing of this ticket.



Solutions?



Bad: not support vCal import

Ok: support vCal import but return a notification to user that 
recurrence events are not currently support

Best:  add support for vCal recurrence rules
2005-04-28 10:39:51 Jan Schneider State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
 
2005-04-28 09:59:42 horde (at) eltofts (dot) homelinux (dot) com Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ SyncML and P900 - repeating entries.
Queue ⇒ Horde Framework Packages
Reply to this comment
Using latest head as of 28/0405



Syncing repeating entries from Kronolith to a Sony Ericsson P900 does 
not create the future repeats. The initial appontment is synced.



Chuck has pointed out that Horde sends v2.0 vcalendar to the client 
and that the P900 does not like this. The P900 send v1.0 which Horde 
does not support.



Quoting Chuck;



RRULE:FREQ=DAILY;INTERVAL=7;UNTIL=99991231

RRULE:W1 SA #0





So here's the problem - apparently vcalendar 1.0 has a completely

different way of specifying RRULEs. We don't recognize the 1.0 way, and

the P900 doesn't like the new 2.0 way. I guess we need version-aware

rrule generation; the easy part will be recognizing the old format and

handling it as well. Not sure if we know what vcalendar version the

client expects during a SyncML session.


Saved Queries