The mid-level modules will contain convenience functions for use in talking to the base modules. Users of these modules shouldn't need to know anything about how iCalendar works. In some cases, that means we'll just be providing nicer interfaces to the base modules, with more do-what-I-mean behaviors than the base modules.
Here's a basic sketch of what we think we want this to look like. Some of this is in CVS so far; most of it's only ideas. If you'd like to grab a piece of functionality to work on, feel free.
Reefknot::Action::* will contain convenience functions for clients to use: propose a meeting, counterpropose an alternate time, reschedule a meeting, etc.
Reefknot::Filter::* will allow us to filter existing Reefknot calendars. "Show me all events this week." "Show me all journals for the last year."
Reefknot::Display::* will contain functions that show iCal data in human-readable formats. These modules will be the base for Reefknot::Client. Some possible namespaces:
Reefknot::Display::Gtk
Reefknot::Display::Text
Reefknot::Display::HTML
Reefknot::Display::Tk
Reefknot::Storage::* will be modules that allow us to save iCal data in various ways and restore it. These modules will provide persistence of data for clients and servers. Modules we've thought about:
Reefknot::Storage::Flatfile
Reefknot::Storage::DBI
Reefknot::Storage::Wombat (for talking to Evolution)
Reefknot::UserDB::* will be modules that allow user authentication from a variety of user systems. These will allow Reefknot to support existing single-sign-on systems that sysadmins may have already deployed. Some possible examples:
Reefknot::UserDB::NIS
Reefknot::UserDB::LDAP
Reefknot::UserDB::ActiveDirectory (?)
Reefknot::UserDB::DBI