gcrkrause
/
gott
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Fix line breaks

main
Georg Krause 2020-02-01 16:50:49 +01:00
parent 9f8688f599
commit 540e656037
1 changed files with 30 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

39
Application-Design.md

@ -1,31 +1,52 @@
# 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:
`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:
1. Read the tracking data
2. Change tracking data based called command
3. save changed tracking data
4. 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.
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.
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.
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.
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.
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
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.
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.
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.