Add Synchronisation section
parent
540e656037
commit
d32805cf98
|
@ -50,3 +50,25 @@ about users anyway. In general it seems to be better to have a strong set of rul
|
|||
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.
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue