SqWebMail
This is currently a work in progress. At this point, the calendaring implementation includes basic calendaring/scheduling resources.
To enable calendaring, create the file calendarmode
in the
configuration directory (/usr/local/share/sqwebmail
, or
$sysconfdir
, usually /usr/lib/courier/etc
). The
calendarmode
file should contain a single word: "local"
echo "local" >calendarmode
Without calendarmode
the calendaring functions are turned
off. At this time, the mere presence of this file enables calendaring,
however it must be initialized this way to allow additional future
functionality.
NOTE - check your umask, calendarmode
needs to be globally
readable.
There are two calendaring modes:
Local mode
Local calendar access requires very little additional resources, in addition to basic webmail support, and it needs very little overhead. Calendaring information is saved in
$HOME/Maildir/calendar
, which is automatically created on first webmail login after calendaring is enabled.Groupware mode
Groupware mode is not yet implemented. Groupware mode offer the ability to synchronize events on multiple calendar. Groupware mode requires additional server resources. A rule of thumb is that groupware mode will require between 10% and 100% of CPU and I/O bandwidth, when compared to basic webmail. Groupware may also require additional disk space, since copies of the event data is copied to each calendar. Events may have large attachments, so allow for plenty of disk space.
In all cases, calendaring is designed to be used in private, non-public settings. This calendaring implementation will not work well in a public webmail environment. Currently, quotas are not implemented on the calendar data. SqWebMail does not work with filesystem quotas. SqWebMail creates cached folder indexes, and an inability to create a folder index will result in a total application failure. SqWebMail does support a software quota implementation, however the software-based quota currently does not include calendaring data. This issue may be addressed in the future.
This calendaring implementation is built on top of an API protocol library that is designed to be flexible and extensible. Only basic calendaring is implemented right now. The API library uses locks when accessing calendar data. Locks are not really necessary in local mode, but are needed for groupware mode. The API library uses dot-lock files, which are designed to work on a network filesystem, as long as the clocks on the clients and servers are synchronized. When a network filesystem is used it is essential to make sure that the clocks on all machines are synchronized with NTP, or an equivalent clock synchronization protocol.
Basic calendaring allows creation and modification of calendar events. A calendar event is handled similarly to mail messages. A calendar event has a subject, and a description. It is possible to attach files to calendar events, similar to how files can be attached to messages. This is mainly useful in groupware mode. Note however that group events place individual copies of the event on each calendar, and large attachments can quickly eat up storage space.
Individual events may be marked as cancelled, or completely removed from the calendar. A cancelled event still appears on the calendar, but new events will not check events marked as cancelled for scheduling conflicts. Adding a new event checks only non-cancelled events for any scheduling conflicts.
Events are created and edited like regular E-mail messages. Until an event is added to the calendar, it is saved in the Drafts folder while it is being edited. To cancel an event without saving it on the calendar, open the Drafts folder, and delete it.
There are some minor design issues that may be addressed in the future.
An existing event is updated essentially by making a copy of it, and saving the updated event as a new event, while simultaneously deleting the old event. It's possible to open an existing event, for editing, more than once. If one copy of the event is placed back to the calendar, the old event information is removed, and the new event information takes its place. If another, previously opened, copy of the old event is opened from the Drafts folder, edited and saved, the updated event already on the calendar is NOT removed, and essentially another event is added to the calendar (assuming no scheduling conflicts with the previously updated copy of the event).
This should not be a major issue, since a scheduling conflict will be reported in most cases, thus bringing this issue to light. Note that it's always possible to manually override any scheduling conflicts, and place conflicting events on the calendar, but a manual override is always required. It's also possible to detect an attempt to save a duplicate updated, because the old event is no longer on the calendar, however this will raise other issues concerning groupware mode. The current approach is the simplest way to implement editing of existing events, and any complications can always be easily fixed by hand.
Calendar events are automatically deleted 30 days after their last occurence.
When asked to generate weekly/monthly/annual recurring dates for an event, until a certain date, the system stops after generating 100 dates. This is to prevent bad input from generating a huge date list.
On most systems, calendaring works only until year 2038, when the 32 bit time counter wraps around. On 64-bit systems calendaring will work beyond year 2038.
Calendaring get the date/time format, names of the days of the week, and
names of the months of the year, from the locale settings. The calendar's
locale can be set by initializing html/en-us/LOCALE
(in the
stock tarball) which is installed either in
/usr/local/share/sqwebmail
or
/usr/lib/courier/share/sqwebmail
by default. Note that the
LOCALE setting will be reflected in all other SqWebMail functions. If the
locale text uses a character set other than iso-8859-1
then it
will also be necessary to initialize the CHARSET file.
If the locale is changed, the sample dates in
html/en-us/newevent.html
may also need changed to reflect the
locale's weekday and month names. Date entry in calendaring uses the locale's
weekday and month names as well. The strings 'tomorrow' and 'today' are also
set in the newevent.html
file - look inside the hidden comments
at the beginning of this file.
NOTE: SqWebMail accepts dates either in MM/DD/YYYY or YYYY.MM.DD no matter what locale is in effect. This is for ENTERING dates only - the dates are always displayed according to the current locale This will be fixed in a future release.