Skip to content

v2.0 Architectural meeting

Jump to bottom Edit New page
Will Law edited this page Oct 15, 2015 · 3 revisions

Thursday October 15th, 2015

Present: Will, Daniel, Karishma, Michael, Dave, Bernhard, Ben, Dan, Jeff, Nathan, Christian, Casey, David, Axel,

Dan/Michael - what do you find complex? What do you want to change?Schedule and rebuffer refactor - easier to read and debug. JIT scheduling, simpler scheduling, appending to sourcebuffer simplified, will merge in to /dev.

Agenda additions:

  1. Project structure - folder/files.
  2. Testing frameworks

Requirements:

    1. Reduce scheduling complexity
    1. Naming conventions needed - be consistent
    1. Modularization/plug-in architecture with loosely coupled code.
    1. Why difficult to include in 3rd party players?
    1. DASH handler can be improved, old methods don't current requirements,
    1. testability, reliability
    1. Biggest pain was rejected requests, now refactored out.
    1. Bower, making accessible, npm.
    1. More modular - have ability to do less,
    1. Manifest handling is not robust, data model tightly bound.
    1. Interface for events
    1. DI model - do we keep, or change. Mostly want to customize ABR controller and fragmentLoader that wraps XHR.
    1. Fall towards simpler side of features if in doubt,
    1. Support for Smooth/HLS - abstraction layer.
    1. Extensibilty.

DI/Modularization How do we get access to objects outside namespace? Module Separation - common.js, ES6, but will not inject dependencies. Can we use dependency management through rules. Could pull out overrideable components, load a different module instead of injection dependency. Configure versus override?

Axel - not that many parts need to be accessed, hard code access points ABR rules - Buffer management XHR requests - for manifests and segments. Events -

Patterns can be applied to modules. Module management could handle these. ES6, common.js could handle. Christian proposed a simple management solution - inversion of control. Allows for unit testing. Also suggested swappable at runtime - common.js - needs browserfy? Could do ES6, using bable, Shaka uses stripped version of closure.Video.js removed in v5 in favor of ES6. ES6 - too early ? Could take existing code base to ES6 and convert. Modularity in project , ES6 is good. babel transpile to ES5. Migration from Dijon. Can we have one event system, vs internal/external? Nathan - should not need many events at all. FRP - streams, series of time events, eg: fragment loading. Event-emitter - basic implementation of events. Events make testability harder. For 1:1, pass functions as callbacks versus dispatch event. Centralize events? not common. Not having events is commonplace. ES6 modules - just apply modules, or modify code for new language features. Get rid of Dijon, use imports, leave ES5 code as is. Christian - start with event-emitter, small refactor, then later replace 1:1 event interactions. How approach plugin architecture - for DRM, or captioning? Events allow loose coupling of components. Testing framework - jasmine, used now. Dijon makes it harder. bower and npm used to download. Michael - project structure. Common practices -

  • move test folder to root
  • multiple package.json -> in root
  • remove grunt dependency, all should be installed with npm install
  • move gruntfile.js to root
  • can remove long.js and math.js,
  • move /lib/ to root from /src/
  • reorganize samples folder - bunch of html, universal template to demonstrate different features.
  • organize sample mpd .
  • jshint.rc moved to root.

Circular dependencies - maybe allowed with Dijon, don't have a way to handle that. proposed modules

  • DRM
  • TEXT/CC support
  • Segment Timelines/Template.
  • Reporting pack
  • DASh/HLS/Smooth. Min files
  • All
  • Core
  • Options
  1. ES6 modules
  2. Event-emitter
  3. Abstract factory pattern with inversion of control to create concrete module implementations.
  4. Jasmine for testing
  5. Node

How to implement:

  1. Who able to core refactor - Michael, Dan,
  2. Helpers - Nathan, Christian, Axel, Bernhard
  3. Freeze PR's against /dev.
  4. Build in /dev. Schedule refactor should be in by next Mon. End of next week, better idea of timeline.
  5. Apply structure changes - perf with npm and bower.
  6. Look at PRs from Bernhard and Dave. PR should be against /dev.
Add a custom footer
Add a custom sidebar
Clone this wiki locally