XBlocks are in many ways the the heart of the realm when it comes to Open edX. It is our oldest plugin interface, and forms the cornerstone of our courseware capabilities. Every video and problem you see in courseware is an XBlock.
I’ve put up an new ADR outlining my current thoughts regarding the role of XBlock in our platform. The tldr version:
XBlocks should continue to be supported, but in a more constrained way. This proposal shouldn’t affect most XBlock types that present just their own contents, but it will affect XBlocks that rely on introspecting content outside of their Unit (e.g. calling up the ancestor tree to see other Units in the Sequence, or querying the root Course block).
We’re creating a set of APIs to allow an XBlock-agnostic model for Sequences, Units, etc. in the LMS. The XBlock runtime would eventually become a peer of other courseware authoring/plugin runtimes that could handle LTI and QTI content, and possibly others down the road.
There are many, many XBlocks out there, most of which I have very limited visibility into. If you think that this proposal might affect you, please comment on the PR (or here, if that’s easier for you). I’m especially interested if your XBlocks do have a use case for traversing the course tree in some way–I’d like to understand those use cases better and see if there are more constrained and targeted APIs that could satisfy them.
Dave, thanks as always for the clear and comprehensive work. Can you say more about the plans for making these changes? What time-frame are you envisioning? Is this work on a near-term roadmap?
Moving top level course hierarchy navigation to a new app is already happening. There are multiple, active, pull requests, and I expect that work to finish in weeks (mostly because we’d also need to shift over some frontend code in the new courseware MFE as well).
But that level of navigation was already pretty separated from XBlocks, as it’s been in the the domain of block transformers for a few years now. The second phase would be for in-sequence metadata. I want to follow up with that work immediately after the top level course navigation work, and to have that in place for Koa, but whether that gets in depends on some internal prioritization related to the new courseware experience.
The last part would be the Unit-level isolation. That’s a more significant undertaking and would almost certainly be something in the Lilac timeframe. But this is the most exciting to me personally, because once we get all the way here, courseware should sing in terms of performance compared to today.
I’m not sure how visible this is outside of edX, but courseware is undergoing the most focused development effort it’s had in years. Whether it’s the new student experience, authoring enhancements, team collaboration capabilities, extensibility (e.g. upgrading and expanding LTI, the start of support for QTI, async messaging, alternative forum systems), tech debt removal, content libraries, grades, performance, security, etc. – there are folks pushing forward on a pretty bewildering number of fronts right now, and both Koa and Lilac are going to be just packed with stuff.
I’m struggling a bit with the phrase “XBlock-agnostic”. When you say:
XBlock-agnostic model for Sequences, Units, etc. in the LMS
Do you mean that you are working on a new model for Sequences, Units, etc. that isn’t expressed or bound to a specific xBlock, or do you mean that it isn’t bound to xBlock runtime in general?
And then I have a separate question altogether: what does this move imply for Blockstore?
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.
Hi Dave,
You are doing a very impressive work I have tried to do it via xblock but mine not working at all please guide me i also want to create a tutorial for this for whole community giving sole credit to you because you is the only person i know who completed this thing please guide me how I can do this or share any repo
I am using Tutor with Nutmeg on ubuntu Docker based Environment
I have used this one
