> 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.
No, I don't think it is. That is the point of Reefknot, which will perhaps use
this module, and extend it, but this in *not* intended to be a comprehensive
interface to iCalendar. The purpose, at least as I am stating it, is to provide
a common language that Date::* modules can talk. Specifically, calendaring
modules, like Date::Discordian, Date::ISO, Date::Mayan, Date::Bhai,
Date::Hebrew, etc, etc.
> 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.
..
I think that you want to look at ReefKnot, which is *much* more what you are
talking about. I'm interested in a rather small subset of that, and I think
that trying to make it all of these other things will really defeat the whole
reason that I wanted to do this in the first place.
--
Rich Bowen - [EMAIL PROTECTED]
Have trouble remembering things?
http://www.idforgetmyhead.com/
