Problem
Bottles::open() loads profiles, initializes HTTP and download services, loads cached catalogs and acquired addons, connects to FVS, and loads Library plugins before returning.
A failure in any of these prevents access to the entire core. For example, a broken Library plugin or unreadable catalog cache prevents inspecting existing native Bottles.
Context reinforces this coupling by requiring these services to be initialized together.
Proposed change
Give the existing services independent initialization boundaries:
- Open Bottle and Program collections without requiring profiles, catalogs, or loaded plugins.
- Load profiles and addon state when opening their respective services.
- Resolve plugin runtimes through the host when invoking their capabilities, as proposed in the Library ownership issue.
- Connect to FVS when an operation first requires it, then reuse the connection.
Keep Bottles::open() as a convenience for assembling the application, but allow callers to open individual managers without initializing unrelated services.
Reduce Context dependencies accordingly. Keep this within the existing crate and reuse the existing managers.
FVS behavior
Lazy initialization must not weaken transactional edits. In an FVS-enabled build, an edit requiring a snapshot must obtain FVS successfully before mutating the environment.
Builds without FVS retain their existing behavior without rollback guarantees.
Problem
Bottles::open()loads profiles, initializes HTTP and download services, loads cached catalogs and acquired addons, connects to FVS, and loads Library plugins before returning.A failure in any of these prevents access to the entire core. For example, a broken Library plugin or unreadable catalog cache prevents inspecting existing native Bottles.
Contextreinforces this coupling by requiring these services to be initialized together.Proposed change
Give the existing services independent initialization boundaries:
Keep
Bottles::open()as a convenience for assembling the application, but allow callers to open individual managers without initializing unrelated services.Reduce
Contextdependencies accordingly. Keep this within the existing crate and reuse the existing managers.FVS behavior
Lazy initialization must not weaken transactional edits. In an FVS-enabled build, an edit requiring a snapshot must obtain FVS successfully before mutating the environment.
Builds without FVS retain their existing behavior without rollback guarantees.