Opened 7 years ago

Closed 7 years ago

#1661 closed enhancement (fixed)

Support adding state managers from bundles

Reported by: Conrad Huang Owned by: Conrad Huang
Priority: major Milestone: 0.9
Component: Tool Shed Version:
Keywords: Cc:
Blocked By: Blocking:
Notify when closed: Platform: all
Project: ChimeraX

Description

Session state managers are useful mechanisms that provide a centralized resource (found via the session) for both managing features (e.g., presets) and for saving state in sessions. Currently, most state managers are initialized by the core (the alignment state manager is initialized from a bundle via custom_init). It would be nice to formalize the process for using bundles to implement state managers and their managed resources because it would help (a) limit number of changes to the core, and (b) allow more frequent updates via the toolshed.

The proposed changes are:

  • Add <Manager> and <Providers> tag to bundle_info.xml schema. These tags translate to ChimeraX classifiers in the generated setup.py file and will ultimately end up as metadata for the toolshed to read.
  • Modify the toolshed to track "generic" state managers and providers in bundles and to initialize managers "at the appropriate time."
    • The Bundle API will need at least two new method: manager_init (for initializing a state manager) and provider_run (for invoking a particular provider, which may be lazily registered to delay importing a bundle package). Other potential methods that may be added as needed include manager_reset and provider_init.
    • The manager_init method is called with the state name (e.g., "presets") to create the state manager instance, which is expected to query to toolshed for providers with the same name. The state manager instance is returned so that the toolshed can register the state manager in the session.
    • The toolshed will treat bundles that define manager_init similarly to those that define custom_init. The bundle package will be imported and the methods called after all bundles have been read in (this is "the appropriate time" for now, although it may be possible to support init-on-demand later). This order is needed to guarantee that the toolshed "knows" all the providers for a state manager before trying to create the state manager. custom_init will be called first, followed by manager_init.
    • Toolshed needs to support run-time ordering of bundles to make sure that "provider" bundles with custom_init methods are called after their state manager has been created. This will require adding another tag to bundle_info.xml.
    • Before "provider" or "manager" bundles are unloaded, methods should be called to notify affected state manager instances. When "manager" bundles are installed, the state manager instances should be created. When "provider" bundles are installed, their state manager instances should be notified.

Change History (5)

comment:1 by Eric Pettersen, 7 years ago

Blocking: 1720

comment:2 by Eric Pettersen, 7 years ago

Blocking: 1720

comment:3 by Conrad Huang, 7 years ago

Resolution: fixed
Status: assignedclosed

Implemented in 895143f2c45.

Added Managers, Manager, Providers, Provider, Initializations, InitAfter tags to bundle_info.xml. Added init_manager and init_provider methods to BundleAPI.

Initialization order is: managers, providers, custom.

comment:4 by Conrad Huang, 7 years ago

Resolution: fixed
Status: closedreopened

Implementation was incorrect because it always initialized providers instead of lazily running them as they are invoked. To delay import, presets_mgr will need to be changed to collect provider information differently.

comment:5 by Conrad Huang, 7 years ago

Resolution: fixed
Status: reopenedclosed

New API implemented and committed 040c391a4.

Note: See TracTickets for help on using tickets.