This concluding section of the functional requirements presents a brief overview of possible future enhancements to the Calendar Tool system. These are enhancements that may be incorporated in a version of the system beyond the initial release that meets the functional requirements defined in the preceding sections of this document.

Here is a list of the possible enhancements:

1. fancy printing and HTML generation
2. more sophisticated undo/redo, including multiple levels of undo/redo
3. more advanced scheduling that takes location attributes into account, such as room size and available equipment
4. addition of a scripting API, most likely Java-based; provide an initialization file that uses the scripting language; provide interactive user access to scripting functionality with a `Command' item at the bottom of the `Edit' menu; allows scripts to be saved to and loaded from files
5. import/export of calendar data from and to other tools, such as Microsoft Outlook, Apple iCal, and in webcal format
6. emacs-style checkpointing and backups
7. user-defined hot key mappings and other UI customization features
8. multiple calendar synchronization, e.g., synchronizing the calendar on a laptop with an office computer; more than two computers should be synchronizable at once, with the effects of synchronization summarized before they're performed; the basic idea is to create one calendar on two or more computers with all of the most recent updates included in the synchronized version of the calendar; cf. Mac OS X's isync utility
9. integration of other popular calendar tool functionality, such as an address book (more user-friendly than the current user database), an alarm- clock/reminder facility, integration with some standardized form of email mailbox
10. smooth integration of HTML content into dialog text fields, in particular allowing HTML links and perhaps other types of tags in the `Details' field of scheduling dialogs
11. smooth integration of unobtrusive and turn-off-able spell checking into dialog text fields
12. allow saving state of open windows relative to today's date, rather by absolute date; see discussion of this in Section 2.8.5
13. provide various command-line arguments to provide initial values that override Settings file, including changing which settings file is read at start up