Application-Design.md

@@ -0,0 +1,29 @@
+# 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:
+
+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.
+
+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. 
+
+## 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.