Assignment 2 - Calendar

Hello, dear friend, you can consult us at any time if you have any questions, add WeChat: daixieit

Assignment 2 - Calendar

You are going to be writing a calendar application that will allow the user to send events to the calendar daemon and keep a record of the events.

You will also be required to construct a number of programs using bash and python. This assignment will involve building some basic unix tools and utilising existing unix tools available to you to perform text processing, basic input and output and some system operations.

The assignment has 4 tasks that you will need to thoroughly test and implement successfully. You have been provided a test suite to assist in developing your solutions.

The four tasks are:

1. implement a calendar daemon program in python that interpret commands received on a named pipe

2. implement a calendar command program in python that sends commands to the calendar daemon

3. implement an initialisation bash script that installs your calendar system

4. create an installation package for your system

Description Syntax

The following is to assist with reading information in this document:

Arguments in the command and protocol structure will be indicated with a : prefix.

Arguments enclosed in square brackets [ and ] are optional.

Parameters that are not further specified can be any string. In order to be considered as one single valid parameter, a string that contains whitespace has to be enclosed by double quotation marks.

Example usage of the following:

● ADD :ITEM -> ADD APPLES

● GET :TABLE :KEY -> GET SUBJECTS INFO1112

● PUT :KEY [:ITEMS] -> PUT BASKET APPLES MILK CAKE

Task 1 - Calendar Daemon

Your calendar daemon application must allow for listening to a named pipe for input. Your daemon will accept a number of commands and process them, these will be used to add,remove,update and retrieve events in the calendar.

Your daemon will need to construct a named pipe within /tmp named cald_pipe which will be used for receiving commands from the command application.

The following messages and their arguments can be received by the daemon via a named pipe.

● ADD :DATE :EVENT [:DESCRIPTION]

Adds a new event, into the calendar’s database, the event requires a date and an event name. Optionally a description can be included with the event itself.

● DEL :DATE :EVENT

Removes an event on a given date, if the event does not exist then nothing will happen. If the event exists, then the event will be removed.

● UPD :DATE :OLDEVENT :NEWEVENT [:DESCIPTION]

This will allow for renaming and updating the event name of an existing event. If the event does not exist, the update should be ignored. If a description has been added to the update, it will update the description to the one specified. 

If no description is specified, this will remove the current description and replace it with an empty string.

In the event an error occurs with the data format, the entry should be rejected. The date format should follow the format DD-MM-YYYY, if the date does not follow the format specified, it should be rejected from being added to the daemon.

All events should be saved to a database that the calendar command can query the data stored.

Database Information and Structure

Your database must be a readable comma separated value (CSV) file. Your database MUST use this format.

The calendar database path will be specified by the first argument of the daemon. If an argument has not been specified, the daemon will create a database file that is in the same directory as the program. For example, if the daemon was executed in the folder /home/user/app/ and no argument was specified initially regarding its location, the database should be create in the directory /home/user/app/.

The default name of the database file (when not specified) is cald_db.csv. The path of the database should be stored in the temporary index file named /tmp/calendar_link.

Errors and error logs

Your daemon should record errors produced within an error file. This file must be named /tmp/cald_err.log. You may assume that you can always create this file.

Task 2 - Calendar Command

The calendar command will find the database file (by reading /tmp/calendar_link) and read the database.

If the calendar command program is unable to find the index file or the database file, the calendar should output

Unable to process calendar database

and terminate.

The calendar command arguments follow this structure.

calendar :ACTION [:ACTION_OPTIONS] [:ARGS,..]

calendar is the program name, other arguments should be command line arguments.

Where :ACTION, :ACTION_OPTIONS and :ARGS (if present) are arguments to the calendar command. The calendar command must support the following actions and their respective options.

● GET, as :ACTION

This action allows exactly one :ACTION_OPTIONS.

This action will allow the command to query the calendar database. It will be able extract events based on their event name, date or a combination of both fields as well as date intervals. These operations will work directly on the database file itself and will not communicate with the daemon.

The GET action can support the following options

● DATE, as :ACTION_OPTIONS

This option allows multiple :ARGS.

This option will specifically allow searching for all events on a specific date. The query will output nothing if there are no events on that date. The option indicates that the following argument(s) will be a date and needs to be interpreted as such.

Example of command.

calendar GET DATE 06-07-1977

This will output all the events that were scheduled on 06-07-1977. If the date is not provided or is malformed, the command must output

Unable to parse date

● INTERVAL, as :ACTION_OPTIONS

This option only allows two :ARGS.

The interval option will allow the user to specify a date interval and extract all events between these days.

calendar GET INTERVAL 06-07-1977 07-06-1978

Two arguments must be provided, start and end. If the start date is after the end date, the command must output the error.

Unable to Process, Start date is after End date

If either date is unable to be parsed, the command must output the error

Unable to parse date

● NAME, as :ACTION_OPTIONS

This option allows multiple :ARGS.

The name option allows searching all events by name. This is a partial match search, allowing for all events that start with the name given. The search is case sensitive.

calendar GET NAME "Birthday Party"

This will retrieve all events that start with “Birthday Party”. If no argument is specified, the command will output the error.

Please specify an argument

When data is retrieved from the database, each entry should follow the output format.

<DATE> : <EVENT> : <DESCRIPTION>

Example:

09-12-2020 : Dentist Appointment : Teeth Cleaning

09-12-2020 : Doctors : Routine Checkup

09-12-2020 : Groceries : Shopping, make sure you get butter

09-12-2020 : Sleep :

The following operations directly interact with the named pipe that the daemon listens to.

● ADD, as :ACTION

This action requires zero ACTION_OPTIONS and two to three :ARGS.

The add command allows inserting new events into the calendar. It must contain a date, event name and optionally a description. If the date is unable to be interpreted, the command must output the relevant error.

Unable to parse date

If an event name is not specified, the command must output the following error.

Missing event name

If other errors or multiple errors occur, the command must output the following error.

Multiple errors occur

In the event that an event and date matches an existing record, the request should be ignored since this is not an update task. The daemon should output an error when this occurs.

The command will be used in the following way.

calendar ADD 19-11-1986 "Jeff's Cake Day!" "It's for jeff!"

● UPD, as :ACTION

This action requires zero ACTION_OPTIONS and three :ARGS.

Similar to the ADD action, the UPD action will update an event and allow for renaming an event and description. The command will be used in the following way.

calendar UPD 18-05-2018 "Tea Break" "Tee Break"

In the event that the date is not well-formed, the command should output.

Unable to parse date

If the event does not exist, the command should output.

Unable to update, event does not exist

If a new event is not specified or the number of arguments is less than three, the command must output.

Not enough arguments given

If other errors or multiple errors occur, the command must output the following error.

Multiple errors occur

● DEL, as :ACTION

This action requires zero ACTION_OPTIONS and two :ARGS.

This will send a request to the daemon to remove an event from the database. The command requires both the date and the event name to match perfectly. It should not accept partial matches.

The command will be used in the following way.

calendar DEL 20-04-2014 "Boring Meeting"

If the date is not provided or malformed, the command must output

Unable to parse date

If the event does not exist, the command should not output anything.

If the event name is not provided, the command must output.

Missing event name

Errors and error log

Errors emitted by your command program must be written to standard error.

Task 3 - Init Script

Once your daemon and calendar command have been completed, you will need to create a startup init script that will run on the virtual machine image provided.

● The init script should start the daemon when user the OS boots.

● The init script must implement restart, stop and start the daemon.

● You will need to include this functionality in the init script itself.

Given the virtual machine image provided, you will need to tailor the init script for this particular image. We will not accept other kinds of init scripts.

Examples of init scripts can be found in the directory /etc/init.d in your virtual machine.

Task 4 - Installation package

Package your application for the virtual machine and construct a script to install it on the linux distribution. Adequately document your package installation and ensure that you also have an uninstall script when the package is required to be removed.

You may use the following guide as a way to get started. https://wiki.alpinelinux.org/wiki/Creating_an_Alpine_package

Checklist

To help with focusing on the problem at hand, you may use this checklist to help organise what features you have to implement.

Daemon

The following are the features the daemon must implement.

● Accepting an optional command line argument

● Creating or reading from an existing database file

● Create a named pipe using the mkfifo function

● Read and wait for messages from the named pipe

● Load data if the database exists

● Parse the commands given by the command program

● Detect the command type and direct to the correct function

● Implement add, update and delete functions

● Error handling

● Test cases for the daemon

Command

The following are features the command must implement.

● Parsing command line argument strings

● Check and read from the temporary file in /tmp

● Check if database and fifo exist

● Implement functions that correspond to add, update and remove functionality

● Implement retrieval functionality

● Output data to standard output

● Redirect errors to standard error

Marking Criteria

Each task has an associated weighting that is a portion of the total marks attainable. As a condition, you will not be able to receive marks for Task 3 and 4 unless task 1 and 2 have been completed. This requires passing all public test cases in tasks 1 and 2.

● Task 1 (6%)

Your grade is derived from your submissions performance in public, private and hidden test cases as well as manual inspection.

● Task 2 (6%) Your grade is derived from your submissions performance in public, private and hidden test cases as well as manual inspection.

● Task 3 (2%)

Your submission for task 3 will require manual inspection and instructions given to set up your start up script.

● Task 4 (2%) Your submission for task 4 will be evaluated manually.

● Test Cases (4%)

Your test cases must cover all execution paths and designed to test specific features. These test cases are only for the executable code section written in python for tasks 1 and 2. Task 3 and 4 do not require test cases.

Each task will require their own set of test cases to show that you have tested your program and have considered all paths of execution.