For anyone reading this, here's the resulting OEP: https://github.com/edx/open-edx-proposals/pull/43
On Monday, August 15, 2016 at 3:34:42 PM UTC-4, Andy Armstrong wrote: > > Hi Martin, > > The conclusion from Slack is that this is a good candidate for an OEP. You > can read about the process here: > > https://open-edx-proposals.readthedocs.io/en/latest/ > > You might also want to look at this PR that extends OEP-1 to support > product changes: > > https://github.com/edx/open-edx-proposals/pull/17 > > We're all new to the OEP process, so thanks for volunteering to be a > guinea pig! Let us know if you need help moving forward. > > Thanks, > > - Andy > > On Mon, Aug 15, 2016 at 3:00 PM, Martin Segado <[email protected] > <javascript:>> wrote: > >> Thanks for the reply! Followup thoughts on some of your points below: >> >> - I like the simplicity of what you are proposing. Using the XBlock >>> runtime's pre-existing loader makes a great deal of sense for the reasons >>> you laid out. >> >> >> ...hat-tip to Peter Pinch for that idea ;-) >> >> - I think some of your use cases would be better handled through XBlock >>> dependencies. For example, IMO a complex feature like code syntax >>> highlighting should be associated with a particular XBlock, rather than >>> being added to an Advanced HTML block. Having the assets tied to the course >>> means that even if the block in question is removed, the assets would still >>> be loaded. It would be better to have them requested on-demand by only the >>> blocks that need them. Having said that, we don't have a mechanism in >>> XBlock to allow multiple blocks to share the same library. >> >> >> Yeah, I see what you're saying - there's definitely a risk of vestigial >> libraries being loaded with this approach (or libraries just being loaded >> earlier than needed). On the other hand, XBlocks also don't seem to me like >> a great fit for syntax highlighting or similar use cases... some specific >> concerns: >> >> 1. Developing new XBlocks requires enough know-how than it's likely >> out of reach for course authors (compared to, e.g., dropping in the >> script/CSS files for PrismJS <http://prismjs.com/#basic-usage> to add >> syntax highlighting course-wide) >> 2. XBlocks have to be accepted/installed into the platform before >> being used [I think?], while scripts/CSS resources can be added >> immediately >> by course authors >> 3. XBlocks can't currently be nested inside <problem> or <html> >> modules, so they're not great for things that might appear interspersed >> with text like code examples or graphs >> >> - There are performance implications to loading a number of individual >>> files like this. Having said that, it would be difficult to have individual >>> courses contribute files to the static asset pipeline, since courses can be >>> created/imported after the LMS has been stood up. >>> >> >> Agreed, though hopefully this will be less of an issue when HTTP/2 takes >> over sometime in the not-too-distant future =) The fact that static assets >> are cached should help in the meantime... it looks like edX sets the >> Cache-Control max-age to 1 year, and external JavaScript CDNs probably have >> fairly efficient caching behavior too. >> >> Let me know where I should go from here. Thanks! >> Martin >> >> >> On Monday, August 15, 2016 at 11:13:33 AM UTC-4, Andy Armstrong wrote: >>> >>> Hi Martin, >>> >>> Thanks for this. The use cases you describe are important, so it would >>> be great to talk through how it can be addressed. I'm not sure if this >>> should be handled as an OEP or not, so I posed that question in our OEP >>> Slack channel (https://openedx.slack.com/messages/open-edx-proposals/). >>> >>> I have a few thoughts to add to your initial proposal: >>> - I like the simplicity of what you are proposing. Using the XBlock >>> runtime's pre-existing loader makes a great deal of sense for the reasons >>> you laid out. >>> >>> - I think some of your use cases would be better handled through XBlock >>> dependencies. For example, IMO a complex feature like code syntax >>> highlighting should be associated with a particular XBlock, rather than >>> being added to an Advanced HTML block. Having the assets tied to the course >>> means that even if the block in question is removed, the assets would still >>> be loaded. It would be better to have them requested on-demand by only the >>> blocks that need them. Having said that, we don't have a mechanism in >>> XBlock to allow multiple blocks to share the same library. >>> >>> - I'd like to consider how such a mechanism should interact with >>> AMD-style loading. We have had some preliminary experimentation with >>> combining XBlocks with RequireJS, and I think it is important to take that >>> into account. >>> >>> - There are performance implications to loading a number of individual >>> files like this. Having said that, it would be difficult to have individual >>> courses contribute files to the static asset pipeline, since courses can be >>> created/imported after the LMS has been stood up. >>> >>> - We might want to make this feature be something that can be disabled >>> if a given installation is not comfortable with giving this power to its >>> authors. As you point out, the power is already there through multiple >>> other mechanisms, so maybe this isn't a concern. >>> >>> Thanks, >>> >>> - Andy >>> >>> On Fri, Aug 12, 2016 at 1:39 PM, Martin Segado <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> Please let me know if this is a good fit for an OEP and I'll put one >>>> together. Also let me know if you would also find such a feature useful! >>>> >>>> *Issue:* I and others would benefit from a way to load course-wide >>>> JavaScript and CSS assets. There are numerous use cases for this: >>>> >>>> - Logging custom events (this alone make the platform even more >>>> valuable for conducting research) >>>> - Consistently styling course content (e.g., by creating classes >>>> for things like callout boxes or image alignment) >>>> - Loading useful JS libraries for things like graphing or code >>>> syntax highlighting >>>> - Trying experimental features (e.g., a course-material search bar; >>>> again, complete with event logging for research) >>>> >>>> *Existing workaround:* It's possible to do this in today's platform, >>>> but it requires adding <script> or <style> tags *to every single >>>> vertical of a course*. Clearly this is suboptimal; it increases >>>> deployment effort (especially when conducting multi-course experiments) >>>> and >>>> may needlessly increase network traffic. >>>> >>>> *Proposed solution: *Add a new policy key (name TBD) for course-wide >>>> assets: >>>> { >>>> "web_assets": [ >>>> "/static/mystyles.css", >>>> "/static/experiment.js", >>>> "//somecdn.com/library.js" >>>> ] >>>> } >>>> >>>> *Proposed implementation:* The courseware template already receives >>>> and renders an XBlock fragment (which includes JS and CSS resources); >>>> additional resources could simply be added to this fragment when the >>>> courseware context is created >>>> <https://github.com/edx/edx-platform/blob/add4d3bce3bd5a9a1a5ce4f3cbf9d416c6eb1ee2/lms/djangoapps/courseware/views/index.py#L373-L437>. >>>> >>>> This approach leverages the existing XBlock/Django infrastructure to >>>> handle >>>> de-duping and rendering, so I expect little code would be needed for the >>>> actual implementation. >>>> >>>> *Possible concerns & mitigation strategies:* >>>> >>>> - Security. Again, though, the ability to include arbitrary >>>> JavaScript in a course *already exists*... this feature just >>>> provides a more elegant way to do so course-wide. It is possible >>>> that making it easier would lead to wider script usage and thus >>>> increase >>>> the odds of users creating a vulnerability; this could be mitigated by >>>> (1) >>>> adding a stern warning to the policy key description about including >>>> scripts only from trusted origins, or (2) limiting this feature to >>>> /static/* files if it's a really big concern. >>>> >>>> - Support. Platform hosts such as edX should make it clear that >>>> this is a power-user feature that would carry *no support* beyond >>>> that for current <script> and <style> tags (i.e., the platform >>>> guarantees >>>> that your scripts will make it into the page, but you're on your own if >>>> they don't work or if something breaks due to platform changes). As >>>> with >>>> security above, it's possible there will be more complaints/support >>>> requests from users simply because of wider script/CSS usage, though >>>> good >>>> documentation and a warning in the policy key description should >>>> hopefully >>>> keep these to a minimum. >>>> >>>> ...Thoughts? >>>> Martin (MITx graduate research fellow) >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "General Open edX discussion" group. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/edx-code/bbab60d8-eeee-4a4c-935d-75715b7ec33a%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/edx-code/bbab60d8-eeee-4a4c-935d-75715b7ec33a%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> >>> >>> >>> -- >>> >>> *Andy Armstrong* >>> >>> edX | UI Architect | [email protected] >>> >>> 141 Portland Street, 9th floor >>> >>> Cambridge, MA 02139 >>> http://www.edx.org <http://www.edxonline.org/> >>> >>> [image: >>> http://www.e-learn.nl/media/blogs/e-learn/edX_Logo_Col_RGB_FINAL.jpg?mtime=1336074566] >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "General Open edX discussion" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/edx-code/24c480ae-231b-4285-a7d6-dd0f37bf855e%40googlegroups.com >> >> <https://groups.google.com/d/msgid/edx-code/24c480ae-231b-4285-a7d6-dd0f37bf855e%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > > > > -- > > *Andy Armstrong* > > edX | UI Architect | [email protected] <javascript:> > > 141 Portland Street, 9th floor > > Cambridge, MA 02139 > http://www.edx.org <http://www.edxonline.org/> > > [image: > http://www.e-learn.nl/media/blogs/e-learn/edX_Logo_Col_RGB_FINAL.jpg?mtime=1336074566] > -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/c2f05cd1-b782-4c2c-8022-68e42d08a96f%40googlegroups.com.
