use Reefknot;

# this is just a sample, and isn't reflective of any exact API
      
# set up information about existing storage and user databases
$store = new Reefknot::Storage::DBI (server => "calserver.myorg.com");
$userdb = new Reefknot::Users::LDAP (server => "ldap.myorg.com");
      
# set up Reefknot to run on top of the storage and user lists
           

$s = new Reefknot::Server(storage => $store,
                          users => $userdb,
                          logdir => '/var/log/reefknot/');
      
# start the event loop
$s->go();
  

# within a CGI program or Apache handler:
      
use Reefknot::Client;
use Reefknot::Storage::Wombat;
use Reefknot::Display::HTML;

# again, just a sample, not reflective of any real API

# set up information about the client
$store = new Reefknot::Storage::Wombat; # use my Evolution calendar store
$display = new Reefknot::Display::HTML; # but do client interface with HTML
      
$c = new Reefknot::Client(storage => $store,
                          display => $display);

$c->handler($cgi);    # or something like this
  

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 will 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, like 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::Render::* will contain functions that show iCal data in human-readable formats. These modules will be the base for Reefknot::Client. Some possible namespaces:

There may be an as-yet-unnamed class that provides calendar display with more interactivity than the Render class. We're not sure about this yet, but the namespace might include:

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::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:

We have very little idea what these will contain. We know that we want them to be very simple to use for people with some Perl experience, mainly system administrators. Some ideas:

Look in the Net::ICal examples/ directory in CVS for a few of these. You might also look in the sketchpad/ directory under the root, which is where we put things until they're categorized.

As of August 2001, we have some targets for what we'd like to see in the first alpha version of the Reefknot modules. This will probably be called either 0.01_01 or 0.01, depending upon how wide we want the release to be.

Reefknot::Storage should be an abstract base class. Subclasses should implement abstracted storage with at least 1, preferably 2 or 3, different types of backends. DBI and plain text are obvious; feel free to volunteer code for others. Reefknot::Storage will use some of the code Martijn's already done for this, probably with method names adjusted slightly.

Reefknot::Render will be an abstract base class. Its subclasses will implement at least one way of showing a calendar —— text suitable for email, perhaps, or HTML. GUI widgets will perhaps come later, but not in the first release. Also, we know that “text suitable for email” will be needed for Net::IMIP, so we may put that code in Net::ICal and use it in Reefknot::Render.

[Unnamed module]: We may eventually have a companion class to Reefknot::Render that's designed to create interactive components like GUIs, and leave Reefknot::Render for static objects. If we do, that'll be in a version after 0.01.

Reefknot::Client will implement at least one client that can receive and send ITIP messages, probably via email using the ITIP mail bindings (IMIP). In the future, we'll want it to talk to a calendar server. It should use pluggable storage from Reefknot::Storage and a pluggable interface from Reefknot::Render. Pluggable interfaces using Reefknot::Render (a web client, a console client) would be nice but probably aren't a goal for 0.01.

Reefknot::Server will eventually implement at least 1 calendar server, probably based on Martijn's “mybits” code, which is in CVS /sketchpad/. This is NOT a goal for 0.01, but we may release some code that leads up to having a server later. It won't do anything but talk to the client, probably speaking CAP to the client. It'll use pluggable storage specified by the calling program that uses the Reefknot::Server module.

Before we can get working server code, there's some other work to do. For both calendaring and scheduling, we'll need to create Net::ICal classes for the new components in CAP (VCAP, VCOMMAND, etc) Then for calendaring, we'll need the equivalent of Net::ITIP for the calendaring commands in CAP.

With this, we should be able to build our first server, which would assume you are everybody and have rights to everything, as we've skipped the “other” bits from CAP. But that'd still be useful for say a backend for a web client where you'd be able to do the authentication on the client end (client being from the point of view of the calendar server, which means the webserver).

We're actively seeking developers with time and energy to work on the alpha Reefknot code. Read on to find out how to contribute.