...

In Editing Context

In Student Context

Proposal 1: Application-centric Runtimes

In this proposal, we would make two fundamental changes to the platform, while preserving backwards compatibility with XModules.

1. Create Application level runtimes (for LMS, Studio, and Studio live-preview).
2. Bind ModuleSystem and DescriptorSystem to those runtimes as XBlock services, rather than as runtimes themselves.

In order for these changes to be successful would need the following:

1. Move all XBlock-runtime methods out of ModuleSystem and DescriptorSystem
2. Change Modulestore and bind_for_children to attach services, rather than modifying runtimes
3. Change XModules and XModuleDescriptors to always use self.system to access ModuleSystem and DescriptorSystem
4. Change self.system to read either ModuleSystem or DescriptorSystem out of the runtime as services, depending on whether self is an XModule or an XModuleDescriptor
5. Make Modulestore use the application-supplied XBlock runtime to construct XBlocks, rather than building runtimes to construct XBlocks

Some possible gotchas in the proposal are

1. Caching: Currently this is done in the DescriptorSystem constructed by the Modulestore. Will that still work in the new proposal?
2. Runtime multiplicity: Currently, we construct one ModuleSystem per XBlock, and depending on the Modulestore, construct one or many DescriptorSystems. How will these be bound onto the Application runtime in order to preserve the current properties, once we switch to having them as XBlock services.
3. How do we build this in an incremental fashion? Does it become an unwieldy long-running branch as we iron out all of the issues above?

Proposal 2: Clean-room XBlock Implementation

In this proposal, we would create an XBlock-only runtime that LMS and Studio could use for courses that contain only pure XBlocks.

Pros

• No backwards compatibility required
• Incremental approach, once we complete the basic runtime, as we migrate existing XModules over to be pure XBlocks

Cons

• Large delta before the new functionality is usable by courses
  • Need a minimal set of pure XBlocks before one could actually run a course
  • Need to write data bindings for FieldData
    • This could be a port of SplitModuleStore
    • This could be a new data storage format
• Need to update all places in LMS and Studio that use Modulestore to use the new pure runtime
  • Unclear whether all modulestore functionality can even be supported yet by a pure XBlock system