Dave: My concerns are reflected in approach memo. Q: Migration side of things , how it’s going to be phased and rolled out
Glib: Want to make it painless. Easiest way - possibly no data migration? Data migration is such a hard problem. How can we eliminate as much migration as possible.
Dave: Do you think there will be a new backend, or gradual conversion?
Glib: Use some utils, should be created from scratch. Perhaps similar to what we implemented with Appsembler a few years ago. Want to create something forkable for customised solutions.
Dave: This new block would map to existing tags?
Glib: Yes - ideally user see same button, but we use new backend. Same metadata for the videos.
Dave: 2u would have to speak to this, but imagine large scale rollout - will want to do for a small # of courses for initial rollout.
Glib: Should be possible to use feature flags
Adolfo: Will this be an XBlock or not? Tentative requirement to render not as an xblock in fe-app-learning? Currently no architectural way to do this. Have you thought about this?
Glib: Still have xblock on backend, but when this data is loaded (rest api) - now have iframes - i have an idea that backend will somehow signal to learning mfe that it’s video xblock, learning mfe goes to backend (missed) render on frontend react using data from xblock. this is an initial thought.
Adolfo: What you seem to be proposing a separate way to render xblocks for a certain number of xblocks, so certain xblocks will render as react components natively (Yes) outside the iframe (yes)
Glib: Have idea that we can render video player in line w/ other components
Dave: Grab what the html of the block should be (there’s an endpoint for this (xblock/v2) that was used for LabXchange), and shove that content into the iframe. I am skeptical of treating components differently in react for future compatibility. when we rebuild the learning mfe in 8 years, the stuff we have shoved into the iframe will work, but this won’t. content lasts longer than code. Concern: reason for this is performance, but i don’t see any measurements of this - all intuition and anecdotes. difference in load time, payload size? I don’t work on the frontend, maybe people know a lot more, but my perspective is that I’m skeptical. I wouldn’t want to hold up work beyond that.
Adolfo: LabXChange: iframe per block. Once way to do, hits lms at endpoint that hands over that block’s html. In my ideal world, we’d convert fe-app-learning to work like that, then we can do whatever we want with the video block w/o interfering w/ anything else. Then you don’t need to do hacky stuff to get new block inside iframe of rest of vertical. out of scope?
Dave: Jeremy was talking w/ OC about doing the above work. Don’t know if 2U is committed to it.
This is still something that they’d like to do, but won’t happen for at least 3 months.
Glib: One of the major points to focus on in first stages, as we still don’t know the exact way to create / implement future player. SHould be a separate repository for backend? Separate xblock? still a part of edx-platform? How we can render in MFE?
Adolfo: I’m reviewing studio frontend work sometimes, interests me as well from that point of view. use me as a point of contact here.
Adolfo: looking at https://openedx.atlassian.net/wiki/spaces/OEPM/pages/3674734593 , MFE Compatibility, “Rework the video component” → shouldn’t take this as biblical. “with no iframe” may not actually be a requirement. Even if it ends up in the same iframe as rest of vertical, still iframe. Given way done so far, no iframe might be too outside the paradigm for it to be in scope for this project.In general, OK to revisit requirements as we do discovery.
Adolfo: Pros/cons of using new tag?
Dave: Data migration. Old tag can use data in place, no new course publish
Adolfo: is that horrible?
Dave: probably a lot of code that checks the tag (eg icon code in vertical title, analytics), so I think it would break a lot of stuff downstream. I get the appeal of something new without legacy baggage though.
Sarina: hard sell/no go to do a course publish on every course
Dave: Explicit transforms that clean up some garbage, some fields that we just drop support for we just don’t have & runtime should not load them.
Dave: VTT conversion?
Sarina: 2U doesn’t want to force SRT → VTT conversion
Glib: Discovery, find that it’s not too difficult to transform the filetypes
Drafts/notes in Confluence that are available to review
Glib: I will clarify thoughts/questions with Dave/Adolfo async, but will ask for sync meeting as necessary
Timeline: about 6 weeks
Create weekly notes of progress, questions, decisions
Create ADRs to describe path forward, why decisions are made
Adolfo: if it was major architectural change affecting full system. Don’t see it as OEP