Skip to content

Define event inheritance semantics #8

@maparent

Description

@maparent

Why do I want event source inheritance?

Use case 1: I want to test a hypothesis, so I make a "branch" of my Source as a different Source, and run what-if scenarios in that Forked Source, while still accessing all the statements in the parent Source.

Use case 2: I want to create a conversation space that can refer to statements both agents have already made in a public thread.

Use case 3: I want to create a community space with aggregate beliefs (for some value of aggregation.)

Current naive implementation: The handler gets the event and the current (source-local) projection state of all projections that the event refers to. Problem: if the event is inherited, I can see many cases where I want the folding function to know more than this.

Use case 4: If a statement has been made locally that shadows a statement in an inherited thread, and the statement is revised in the inherited thread, I may want to (4a) keep shadowing the value (priority to local values) or (4b) to mark the projection as conflicting (since the shadowing may not be valid for the new statement.)

What is the minimum information that the handler needs access to for this use cases? Ideally it should not need knowledge of past events, so the information must be encoded in the projection.

First stab: The projection could contain the timestamp of the last local event, and a dict giving, for each source directly inherited, the last known event and the last known event that was resolved. If the last known (unresolved) event is later than the last local event, there is a known conflict, and a need for resolution. (It could be automatic in simple cases.)

I could also see a case for the handler of inherited events also having access to the projection state in the inherited thread and how it was affected by that same event. (So at least the state after, and maybe also before.) Note that inherited projection state may well be using a different schema (e.g. aggregation awareness may exist only in the containing thread.)

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

Status

Todo

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions