On Sat, 5 May 2001, Martijn van Beers wrote:
> Do we want the internal representation to be a string?
>
> glib's date format is:
<snip/>
I think .. both. The module isn't useful without a method get-set struct
of some kind, but it should also allow access to the string. Meaning, the
usefulness of the base Time::Date or whatever module is that it parse,
build the struct, and give access to the elements. Much like the XML APIs
do for XML docs. (It's worth noting that there is an iCalendar schema
that I've been using for a while in several Perl apps already; bummer
that more apps don't:
http://www.oasis-open.org/cover/draft-dawson-ical-xml-dtd-01.txt.) Set
methods should allow individual elements to be set, and then build an
iCalendar string, sorta like XML::Writer.
(Also, please note that "iCal" is not quite accurate; picky, but there's
so much out there called "iCal" that it's bound to confuse lots of folks
otherwise.)
Perhaps I'm not thinking in the same vein as others. But since the primary
intent is a comprehensive interface to iCalendar, all effort should be
made to conform any internal representations to the RFC fields. Beyond
that, descendant modules may enable whatever type of localized interface
they want. That's the whole idea. I think.
So, why are we talking about the datetime representation and such? I mean,
that's great, but nobody will agree on it. The point of iCalendar's
VTIMEZONE component is that issues such as timezones are mostly
orthogonal. Besides, time is such a small part of iCalendar anyhow.
Locations, groups, attendees, roles, rsvp's, recurrence, event classes and
categories, alarms and reminders are all part of the format. Heck, it's
even supposed to do journal entries and encoded binaries. As these are
"objects" within the format, nestable and inter-referrent, it seems that a
subclass for each iCalendar component would be appropriate, such that you
could iterate the data as, say:
for my $event ($ical_document->vevents)
{
if ($event->class eq "PUBLIC") {
print "Summary: ", $event->summary, "\n";
print "Location: ", $event->location, "\n";
print "Time: ", $event->dtstart, "\n"; # or parse it
# somewhere else
}
}
Although the interface I throw out is probably objectionable, and overly
optimistic. I don't care what the interface looks like: iCalendar is the
standard; the interface is less crucial. But important just the same. This
is essentially how my code works based on the iCalendar XML schema;
get/set methods for the fields of each object, nesting objects, and
printing the objects outputs an iCalendar XML doc. I'm biased, but I would
think this module should do the same with the standard iCalendar format.
I may be offering more input than is desired, or addressing stuff that has
already been addressed. But I think a good initial goal for the project
would be this module, which would probably most appropriately be called
simply "iCalendar", or some derivative under "Time::".
Dan
