Skip Menu |

This queue is for tickets about the iCal-Parser CPAN distribution.

Report information
The Basics
Id: 56689
Status: rejected
Priority: 0/
Queue: iCal-Parser

People
Owner: Nobody in particular
Requestors: Nathan.Bailey [...] its.monash.edu
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: 'add_event' assumes 'UID' but I'm not sure it's required?
Date: Sun, 18 Apr 2010 10:00:32 +1000
To: bug-iCal-Parser [...] rt.cpan.org
From: Nathan Bailey <Nathan.Bailey [...] its.monash.edu>
Line 309 of Parser.pm assumes the existence of a 'UID' attribute, but it isn't clear to me (from http://www.ietf.org/rfc/rfc2445.txt) that UID is a required attribute? 309: $self->find_day($event->{DTSTART})->{$event->{UID}}=$event; The following perl script (based on Data::ICal::Entry::Event's POD), doesn't generate a UID as part of the event: use Data::ICal; use Data::ICal::Entry::Event; use Date::ICal; my $calendar = Data::ICal->new(); my $vevent = Data::ICal::Entry::Event->new(); $vevent->add_properties( summary => "my party", description => "I'll cry if I want to", # Dat*e*::ICal is not a typo here dtstart => Date::ICal->new( epoch => time )->ical, ); $calendar->add_entry($vevent); print $calendar->as_string; (in fact, Data::ICal doesn't seem to have an UID generating code - otherwise I'd use it to overcome this :-) I would be happy if Parser.pm created UIDs as part of its parsing process, but if you don't want to change the integrity of the original iCal content, perhaps you could use a different (internal) key? thanks! :-) N
Subject: Re: [rt.cpan.org #56689] 'add_event' assumes 'UID' but I'm not sure it's required?
Date: Sun, 18 Apr 2010 11:34:37 -0400
To: Nathan Bailey via RT <bug-iCal-Parser [...] rt.cpan.org>
From: Rick Frankel <rick [...] rickster.com>
On Sat, Apr 17, 2010 at 08:00:54PM -0400, Nathan Bailey via RT wrote: Show quoted text
> Sat Apr 17 20:00:53 2010: Request 56689 was acted upon. > Line 309 of Parser.pm assumes the existence of a 'UID' attribute, but > it isn't clear to me (from http://www.ietf.org/rfc/rfc2445.txt) that > UID is a required attribute?
4.8.4.7 Unique Identifier Property Name: UID Purpose: This property defines the persistent, globally unique identifier for the calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property MUST be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. Show quoted text
> (in fact, Data::ICal doesn't seem to have an UID generating code - > otherwise I'd use it to overcome this :-)
Sorry, I'm not familiar w/ Data::ICal, but it seems from the above rfc section that the UID is required on a VEVENT. Show quoted text
> I would be happy if Parser.pm created UIDs as part of its parsing > process, but if you don't want to change the integrity of the original > iCal content, perhaps you could use a different (internal) key?
This wouldn't work, as the whole point of the UID according to the spec, is to associate multiple vevents in the file/multiple files. iCal::Parser pretty much depends on this to build its internal representation. rick