Opened at 2010-02-22T00:52:19Z
Last modified at 2025-05-30T14:15:26Z
#540 new todo
Session mutation handling
| Reported by: | Ichthyostega | Owned by: | |
|---|---|---|---|
| Priority: | urgent | Milestone: | 1alpha |
| Component: | lumieraSteam | Keywords: | FocusTopic design session sanity roadmap |
| Sub Tickets: | #212, #541, #542, #558, #559, #560, #561, #567, #1234, #1406 | Parent Tickets: | #14, #76, #143, #332, #1327 |
Description (last modified by )
As Lumiera Architect,
I want a consistent concept how to handle any change to Session contents,
as foundation for decisions regarding resolution of Placement and media Stream Types.
Fundamental Architecture Decision
Anything with a tangible effect on the Render will involve a mutation of Session contents
This brings about the decision how actually to manipulate and change the High-level-Model.
- do we expose manipulation of Placements and MObjects over external APIs?
- will Commands directly manipulate Session contents and are these changes persistent?
- is any form of »Event Sourcing« introduced, and where is the point to emit the Events?
From a user perspective, we want a viable »UNDO« function and our vision is even to allow revising and changing any decision taken. This goal points in the direction of a declarative model, which is the essence of »non-linear editing«. Yet driving this goal to full consequence leads to an »Event Sourcing« scheme, which should be complemented by an Architecture of »Command and Query Responsibility Separation«. But driving both aspects to full consequence incurs a hidden danger: a declarative model implies some kind of a rules language — which may produce tangible changes all by itself, just by resolving the rules within the given context of setup and parametrisation. So we are driven to use a precise and consistent definition of what comprises a change and how to emit and replay Events.
So this is essential concept work. From there we get to practical conclusions regarding how model contents can actually be manipulated. We have to ensure any mutations of the high-level model are handled in a sane manner, always leaving the model in consistent and reproducible state.
Change history (6)
comment:1 by , at 2010-03-07T00:03:44Z
| blockedby: | 212, 541, 542 → 212, 541, 542, 558, 559, 560, 561, 567 |
|---|
comment:2 by , at 2022-10-21T22:40:37Z
| Description: | modified (diff) |
|---|
comment:3 by , at 2023-09-12T18:00:38Z
| blocking: | 14, 76, 143 → 14, 76, 143, 332 |
|---|---|
| Description: | modified (diff) |
| Keywords: | FocusTopic design roadmap added; QA removed |
| Priority: | normal → urgent |
| Summary: | Sane mutation handling → Session mutation handling |
| Type: | planned → todo |
comment:4 by , at 2023-09-13T18:58:35Z
| blocking: | 14, 76, 143, 332 → 14, 76, 143, 332, 1327 |
|---|
comment:5 by , at 2025-05-30T14:15:26Z
| blockedby: | 212, 541, 542, 558, 559, 560, 561, 567, 1234 → 212, 541, 542, 558, 559, 560, 561, 567, 1234, 1406 |
|---|
comment:6 by , at 2025-12-25T00:00:00Z
| blockedby: | 212, 541, 542, 558, 559, 560, 561, 567, 1234, 1406 |
|---|---|
| blocking: | 14, 76, 143, 332, 1327 |
| Parent Tickets: | → 14, 76, 143, 332, 1327 |
| Sub Tickets: | → 212, 541, 542, 558, 559, 560, 561, 567, 1234, 1406 |
Migration MasterTickets ⟼ Subtickets-plugin

While compiling a list of »Focus Topics« to define the further direction of Lumiera development (after the crucial integration slices currently worked on are completed) it became clear that there are some deeply entrenched inner conflicts in the design built thus far, which must be resolved eventually. These are related to Events, Mutation, Sanity and the role of Placements in the model.