Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Refactor Session Management to Project-Wide Level #44

Closed
maximmaxim345 opened this issue Oct 17, 2024 · 2 comments · Fixed by #78
Closed

Refactor Session Management to Project-Wide Level #44

maximmaxim345 opened this issue Oct 17, 2024 · 2 comments · Fixed by #78
Labels
component: project

Comments

@maximmaxim345
Copy link
Owner

maximmaxim345 commented Oct 17, 2024 •
edited
Loading

Refactor the Session to be handled on a ProjectSession wide level instead of DataSession. This change will synchronize data stored in the Session and Shared data sections across all DataSessions created from the same ProjectSession.

Description

The current implementation manages sessions at the DataSession level. The proposed refactoring will elevate session management to the ProjectSession level, ensuring consistent data across multiple DataSessions within the same project.

Benefits

  1. Synchronized data: The Session and Shared data sections will be consistent across all DataSessions derived from the same ProjectSession.
  2. Improved consistency: When working with multiple DataSessions simultaneously, such as modifying a sub-part in an assembly, behavior will be more predictable and consistent.
  3. Project-level undo/redo: The undo/redo functionality will now operate at the project level. Avoiding inconstant behavior.
@maximmaxim345
Copy link
Owner Author

maximmaxim345 commented Oct 18, 2024 •
edited
Loading

Notes

  • To be compatible with a CRDT based data storage (Implement CRDT for Data Sections #45), a Project should store a single list (log) of all Transactions/undo/redo markers.
  • Operations on documents like creating/deleting/renaming should also be stored in the log.
  • Running this log sequentially (while leaving out Transactions previously marked as undone) should output the complete state of the whole project (including the state of all documents and data sections).
  • This continuously gowning list can then later be changed into an CRDT.
  • Modules would then no longer need to implement a manual undo strategy.

@maximmaxim345 maximmaxim345 moved this to In progress in CADara Oct 18, 2024
@maximmaxim345
Copy link
Owner Author

Implementation Ideas

  • Project stores:
    • Sequential log of all transactions (including undo/redo and project management operations like new/delete/rename document) -> stores all data required for building all PersistentData and PersistentUserData sections
    • Data of all SessionData sections. -> will directly be visible
  • Data in a Project can not be directly accessed, creating a ProjectSnapshot is required
  • ProjectSnapshot provides a atomic read only view into everything stored in the Project.
  • ProjectSnapshot can be used to generate a ProjectTransaction, which describes all changes to be applied simultaneously
  • a ProjectTransaction can be applied to a Project.
  • a ProjectTransaction is atomic, meaning: when undone, it will be undone as a whole.

Open Questions

How will SharedData be stored?

We don't have yet decided how SharedData should exactly work. Two options seem plausible:

  1. Every uses has a separate SharedData section that is visible by everyone, but only editable by the owner
  2. SharedData should behave exactly like a PersistantData section, that is just reset after all users "log out"

How specific should a ProjectTransaction be?

Should it include multiple changes or be specific to a single Transaction?
If it can include multiple changes, should it be still limited to a single data section?

@maximmaxim345 maximmaxim345 mentioned this issue Dec 18, 2024
Merged
@maximmaxim345 maximmaxim345 linked a pull request Dec 18, 2024 that will close this issue
refactor(project): Refactor Session Management to Project-Wide Level #78
Merged
maximmaxim345 added a commit that referenced this issue Dec 18, 2024
@maximmaxim345
refactor(project): Refactor Session Management to Project-Wide Level (#…
fca90f6 
…78)

Closes #44

**Description:**

This pull request refactors the session management system to operate at
the `ProjectSession` level instead of the `DataSession` level. This
change centralizes session and shared data handling, ensuring
consistency and synchronization across all `DataSessions` derived from
the same `ProjectSession`.

**Key Changes:**

1. **Centralized Session Data:** `SessionData` and `SharedData` are now
managed within the `Project` struct, making them accessible to all
`DataSessions` within that project.
2. **Simplified Data Access:** `ProjectView` now provides a unified view
of a project's state at a given point in time, simplifying data access
and manipulation.
3. **Atomic Transactions:** `ChangeBuilder` now records changes to be
applied atomically to a `Project`, supporting project-level undo/redo
and improving data consistency, especially in collaborative scenarios.
4. **Unified Change History:** A single chronological log of
`ProjectLogEntry` is used to track all changes, enabling persistent
undo/redo and supporting version control features like branching and
merging.
5. **Enhanced Collaboration:** The new architecture supports multi-user
collaborative editing with offline support by design, using the
`ProjectLogEntry` to synchronize changes between users.
6. **Removed `DataSession`:** The `DataSession` concept has been removed
in favor of direct manipulation of `DataView` and `PlannedData` through
`ChangeBuilder`.
7. **Renamed `DocumentSession` to `DocumentView`:** Renamed
`DocumentSession` to `DocumentView` to better reflect its role as a
read-only view into a `Document`.
8. **Module-Specific Operations:** The `ModuleRegistry` now holds a
v-table (`ModuleRegistryEntry`) for each registered module, enabling
runtime polymorphic operations on module-specific data types.
9. **Serialization/Deserialization:** `ProjectDeserializer` is used to
deserialize projects, leveraging the `ModuleRegistry` to handle
module-specific data.

**Benefits:**

* **Data Consistency:** `SessionData` and `SharedData` are synchronized
across all `DataSessions` within a project, eliminating inconsistencies.
* **Predictable Behavior:** Concurrent operations on different parts of
a project (e.g., modifying sub-parts of an assembly) are more
predictable and consistent.
* **Project-Level Undo/Redo:** Undo/redo operations are now managed at
the project level, simplifying the implementation and ensuring
consistency across all documents and data sections.
* **Simplified API:** The API for interacting with projects is
simplified, with `ProjectView`, `DocumentView`, and `DataView` providing
read-only access and `ChangeBuilder` enabling controlled modifications.
* **Foundation for Advanced Features:** The new architecture provides a
solid foundation for future enhancements, such as CRDT-based data
storage, real-time collaboration, and advanced version control.
@github-project-automation github-project-automation bot moved this from In progress to Done in CADara Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: project
Projects
CADara
Archived in project
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

refactor(project): Refactor Session Management to Project-Wide Level maximmaxim345/cadara
1 participant
@maximmaxim345