Application Design

Basic principle

gott basically tracks time by writing current timestamps to a file (or later maybe to an abritary API). So the basic workflow of the application is the following:

Read the tracking data
Change tracking data based called command
save changed tracking data
Write useful status information to stdout

While the first step obviously is necessary, step 2 might be skipped, eg for simple print commands. If no data is changed, saving can obviously be skipped, too. Step 4 can be omitted, too, but gott should always make clear what its internal state is currently.

Since gott is meant to envolve into an environment of different peaces which allow synchronized tracking from all devices, there are some special requirements.

At first the data storage layer should be replaceable on runtime. Maybe later on gott can operate as a client to a running server and handles data through the servers API. Currently only local file storage is supported, maybe there is a need to support different data formats. Depending on the scalability of the current file based implementation it might be also useful to make use of databases for storing the data.

Furthermore the output of the commands should be available as machine-readable information. This way Desktop-GUIs could be developed quite easyly by simply interacting with gott instead of implementing all the data handling itself. This might be also true for data input.

The default should be a binary without any dependencies (eg databases) which can be easyly run on any system, like small SBCs or any server or even on your linux smartphone without the need to install anything else.

Data storage

Currently and for the near future all the data is stored in simple JSON files. The format is quite simple. A record consists of the following information

Start time
End time
list of tags

For now thats basically everything. Its desirable to keep it as simple as possible, to avoid problems and keep the system flexible. Still, there might be a need for some other information like an ID and some caching information in order to allow a good working synchronisation. There is some investigation needed which model is known to work best. For now its sufficient.

Another extension might be needed in order to allow tracking in teams with different users on different projects. Projects might be pretty well represented by using tags. I am not that sure about users anyway. In general it seems to be better to have a strong set of rules instead of high flexibility which gets implemented by each software in another way, and therefore leads to missing interoperability. So if the information about the user is really needed, there should be another date field for it.

Synchronisation

There are two uses cases for for what we basically call synchronisation. On the one hand users want to be able to access and modify their records from any device in use. On the other hand users might be interested in sharing their records, eg with their companies time-tracking system. These are different aspects and there need to be different mechanisms to support them both the right way.

Synchronisation is a multilateral process. There are several participating devices. Usually each device should be able to modify the records. This leads to the possibility of conflicting changes and there needs to be a way to handle them. To avoid overhead there needs to be a way to reduce the amount of synchronized data by only updating whats needed, but on the other hand we must not miss any changes.

The usecase to push changes to centralized tracking system used eg by your company or send tracked records into your issue tracker has other requirements. This is more like an export. There need to be service specifiy mappings from tags to whatever meta-data is required by the service (eg projects, issue number...). There is probably no need to pull any changes made on these platforms back into your system.