Meeting 2023-05-26 Architecture
Participants
- Paul
- Thorben
- Moritz
- Samuel
- Lukas (Zuhörer)
Questions
The main architectural questions are:
-
current state? (layers state+backend)
- array, actions
-
lock
-
When to submit data to the backend?
-
multi-player?
-
SSE
-
How to send data to the backend?
- array von actions
-
How to get updates from the changes of other users?
-
Scope of versions, undo/redo
- tracked/untracked history
-
how separated are layers
-
Collaborative vs. Offline
-
Locking of layers
-
undo/redo
-
removing versions?
-
timeline (createdAt, deletedAt) -> many year span not considered yet
-
actions associated with layer
-
map owner can remove locks
-
without lock offline: read-only state
-
lösung:
-
backend always up-to-date
-
collaborativ: see what others are doing
-
only conflicts in most recent actions
-
undo/redo history gets purged on movement
-
lazy loading of layers (not years)
-
we need reverse actions
-
separated from it then IS-state (not initial)
-
begin, end date different to delete!
-
coordinates: konva coordinate CSS pixel = 1cm
-
objects: x,y,scale,color, shape, ID, rotation
-
per layer API calls
-
plant API calls:
- search (text) -> list of plants
- plant_info () -> info, list plant_ID of relations, array of 1m raster, maybe picture/heat map
- place_plant (plant_ID, pos, date)
-
map versions löschen
-
remember which objects are loaded?
-
elemente in DB store
-
outcome:
- moritz: auth, image, pixels docu
- paul: lazy loading, state management
- samuel: NC, state
- Thorben: remove versioning, map duplication
We would then have to keep track of the undo/redo history for each user on the backend as well. -> we don't do The read-only users should only have the latest version of the data + their local changes in the history. Without keeping track of the undo/redo history on the backend, sending a new version to the backend at a fast pace would clutter it.
Please also read (with my comments): https://github.com/ElektraInitiative/PermaplanT/pull/382/files
Meeting Notes
-
Undo/Redo
-
Current plan:
- base state + actions taken until now
- synchronize with backend via version creation, backend takes actions and builds new base state
- proposition: save actions in backend to restore lost sessions
- could cause synchronization problems with offline functionality
- implement locks on layers to reduce synchronization conflicts
- problem: what happens if user loses lock while offline and then comes online again
- "multiplayer" szenario: every user tracks only their own history
- how does undo/redo interact with very old changes (e.g. 10 years ago)
- do not load every data, only when needed (lazy loading)
- remove local history of one layer if another user made changes on it
-
new plan:
- directly push changes to backend
- every layer has its own endpoints
- history holds undo actions
-
Frontend map store
- tracked and untracked states
- tracked: affected by undo/redo
- untracked: configurations (e.g. layer opacity)
- layer independent store => to be used by all layers
-
Backend interaction with offline use case
- lock backend writes on map when going offline
- offline capability as a grantable permission for collaboration
- map owner should be able to revoke write lock in case of an abuse of offline mode
- as a first step no write lock, instead read only when offline
-
Save creation and disable dates for every element, "deleting" a plant sets it disabled to still be able to view it in the timeline
-
Position of elements will not be saved for the timeline and instead gets overwritten with every coordinate change