One that isn’t bound to the XBlock runtime in general. The LMS would have its own concept of Sequences and Units that may contain XBlocks, or may contain other types of content like QTI. Or may elect to pull individual XBlocks from a variety of different places, customized for a particular user.
But in all of these cases, the publish process pushes XBlock data into a new system with its own data model.
Blockstore fits very naturally into this worldview, as this type of separation was in the back of our minds when we were developing it.
The story of Open edX courseware to date has mostly been the story of XBlock. From the navigation, to interactions with individual problems, all the way down to the scope-oriented storage layer–everything is very XBlock specific.
Both the navigation work described in this thread as well as the storage work in Blockstore represent a way of stuffing XBlock into a smaller box and allowing new, tightly focused, but more broadly reusable systems to emerge. Blockstore stores versioned snapshots of files and tracks dependencies for different pieces of content. It’s a simple storage layer that gives a few specific capabilities, but it has no understanding of XBlock or XBlock concepts. The XBlock runtime can use Blockstore to serialize data to, just like it can use the new learning_sequences app to create the navigation hierarchy of a course. But so can other things.
Want to store QTI in Blockstore? Videos from the video pipeline? PDFs? Blockstore doesn’t care. It just knows you have some bundle of files and maybe it depends on some other bundle of files that you’d like notifications about.
In the same way, the LMS is going to have its own concept of Course navigation, Sequence navigation, and Units–each of which represent a different layer of composition. The publishing process is going to query the XBlock runtime and push all kinds of data into these systems. But in a couple of years, I could see us in a place where we have something like:
Cross-Sequence Navigation:
- Traditional Courses
- LabXchange-styled Pathways
Sequence Navigation:
- Traditional Sequences, where the contents are fully known at render.
- Adaptive Sequences that change over time.
Unit Rendering:
- XBlock content
- LTI (independent of an XBlock)
- QTI
- a new, more front-end focused pluggable framework
One of the things that folks might notice is that even with the new work in learning_sequences, the new courseware MFE work is being built to make separate requests for:
- Course outline data
- Sequence metadata
- Unit rendering (in an iframe)
We could have merged the course outline and sequence metadata into one request and made things a bit more efficient. But we’re intentionally keeping that separation because we might want entirely different sequence types. Maybe that new Adaptive Sequence type doesn’t support indexed access into its units because it’s doing some stateful progression. The Course Outline doesn’t understand how any of the sequences actually work, just that they are composed in some ordering, have some basic agreed-upon metadata, and have types/URLs associated with them. Adding a new Sequence type doesn’t require any changes to Course-level navigation. The same story could apply in the relationship between Sequences and Units.
There’s a lot involved in hammering out those boundaries, and there will be many challenges along the way. But for me, this is Open edX’s future as a Open Learning Platform–not one all-encompassing framework like XBlock, but a collection of primitive concepts (Unit, Sequence, Cross-Sequence) and low level APIs that can be composed in powerful and scalable ways.