Requirements Specification

General Notes

Deployment

1. The calendar must be able to be distributed as a jar file in order that it can be configured and used in a closed environment, i.e. a simple single class application.
2. The calendar service must be deployable in a cloud environment and must undergo configuration from external sources only. Configuration sources may be: csv files, database or external service.

Query Language

1. A query language will be created that allows lexical analysis and parsing of various type of query.
2. A grammar will be created that supports calendar creation, update, selection and deletion.

Query Service Facility

1. A query service must be provided that allows administration of calendars via a ReST interface; a transactional creation, update and deletion.
2. A query service will be provided that allows read-only access of calendars that can be identified by name or ID.
3. Authorization for read access must not include write access by default.
4. All non-read access must be fully audited against individual users and be made available for external viewers to read.

Durability

1. Calendars that are created and modified must be persisted but the module that performs this must not be tied to a specific persistence technology.

Client Access

1. Clients can access calendars by submitting an HTTP query to a service or by using a calendar object directly. This goes for both types of deployment. For service based deployments, if a calendar object is required locally, then the SDK will obtain it in serialised form from the remote service and reconstruct it locally.
2. All client access is to be performed using client API keys.