This is a fair assessment of the challenges / divergent code bases. In terms of a path forward, I think it’s worth highlighting how the Kaltura player normally integrates with other stand alone entity providers now days. We normally integrate via a media proxy library that basically normalizes representation of stream sources, media identifiers, structured and unstructured metadata, captions, cuePoints, content security protocols to a “Kaltura like” representation then the CMS’s consume the kaltura player iframe services in a way that is almost identical to our Kaltura Platform style embeds, just overriding identifiers. This makes the iframe player service easy to be consumed by our native components, twitter embeds etc. See architecture overview here. [1]
You can see what this looks like with a mediaProxy override sample [2] Is this useful for wikimedia use case? … not so sure ... since the review scope would grow a lot if we had the player serving its own iframe independently of the rest of code infrastructure it would otherwise duplicate many components, and reduce insensitive to align versions of things. Some significant brainstorming and alignment would need to take place which has awaited a focus from the multimedia team; since we would want to focus efforts towards something that would be sustainable for both organizations going forward both from community and organization contributions so the projects could better benefit each other. * Kaltura will move quickly to review and integrate the code styling / js-hint updates something we have intended to do for a while. Other low hanging fruit alignments have already been integrated, by some early work on this by paladox2015 ( github id ). * Kaltura would be interested in working to make things as easy as possible to use the library in both context; but we need “a plan”. While things have drifted significantly there is paths towards upgrading things, a goal to align code conventions [3] means the projects share a lot more then say some arbitrary other project out there that would do everything its own way ;) * That being said, the possibility for WMF to use something new should evaluated, but again should involve multimedia team within WMF so that the cost benefit analysis can be mapped out per organization infrastructure support; or a similar situation will crop up after a sprint of effort produced something usable, but was not maintained going forward. [1] http://knowledge.kaltura.com/sites/default/files/styles/large/public/kaltura-player-toolkit.png <http://knowledge.kaltura.com/sites/default/files/styles/large/public/kaltura-player-toolkit.png> [2] http://kgit.html5video.org/pulls/1194/modules/KalturaSupport/tests/StandAlonePlayerMediaProxyOverride.html <http://kgit.html5video.org/pulls/1194/modules/KalturaSupport/tests/StandAlonePlayerMediaProxyOverride.html> 3] https://github.com/kaltura/mwEmbed/#hacking-on-mwembed <https://github.com/kaltura/mwEmbed/#hacking-on-mwembed> > On Dec 11, 2014, at 7:55 AM, Derk-Jan Hartman <d.j.hartman+wmf...@gmail.com> > wrote: > > So for a while now, I have been toying a bit with > TimedMediaHandler/MwEmbed/TimedText, with the long term goal of wanting it to > be compatible with VE, live preview, flow etc. > > There is a significant challenge here, that we are sort of conveniently > ignoring because stuff 'mostly works' currently and the MM team having their > plate full with plenty of other stuff: > > 1: There are many patches in our modules that have not been merged upstream > 2: There are many patches upstream that were not merged in our tree > 3: Upstream re-uses RL and much infrastructure of MW, but is also > significantly behind. They still use php i18n, and their RL classes > themselves are also out of date (1.19 style ?). This makes it difficult to > get 'our' changes merged upstream, because we need to bring any RL changes > etc with it as well. > 4: No linting and code style checks are in place, making it difficult to > assess and maintain quality. > 5: Old jQuery version used upstream > 6: Lot's of what we consider deprecated methodologies are still used upstream. > 7: Upstream has a new skin ?? > 8: It uses loader scripts on every page, which really aren't necessary > anymore now that we can add modules to ParserOutput, but since I don't fully > understand upstream, i'm not sure what is needed to not break upstream in > this regard. > 9: The JS modules arbitrarily add stuff to the mw. variables, no namespacing > there. > 10: The RL modules are badly defined, overlap each other and some script > files contain what should be in separate modules > 11: We have 5 'mwembed' modules, but upstream has about 20, so they have > quite a bit more code to maintain and migrate. > 12: Brion is working on his ogvjs player which at some point needs to > integrate with this as well (Brion already has some patches for this [1]). > 13: Kaltura itself seems very busy and doesn't seem to have too much time to > help us out. Since some of the code is however highly specific to their use > cases, it becomes difficult to validate changes. > > Oh and the file trees are disjunct between us and upstream, making git > merging a lot more troublesome than it should be (anyone got tips ?). > > This is maintenance hell, we need to come up with a plan here or we are going > the way of getting so far out of sync that the cheapest solution will be to > start from scratch... > > So my questions: > 1: Is there anything in upstream that we actually want ? I've been hearing > about the 'update' that was still coming from there for over a year now, but > due to how far both trees are now out of sync, i'm not really holding my > breath for that anymore. The last 'proper sync' seems to have been 'Kaltura > 1.7' in july 2012.[2] They are now at v2.21.9 > 2: Who can think of a strategy to fix this ? > 3: Or should we just split off our modules and let upstream sort this out ? > 4: Should we consider starting something from scratch ? > > DJ > > I have done a bit of cleanup [3] with jshint and jscs on the modules that we > use. There are some remaining problems [4], some of which are true bugs in > the code. I don't intend to propose these changes for merging any time soon, > since it will probably make consolidation of the two variants even more > complicated, but I'll try to keep it up to date and maybe try to fix some of > these bugs upstream or in MW. > > [1] https://gerrit.wikimedia.org/r/#/c/165477/ > <https://gerrit.wikimedia.org/r/#/c/165477/> > https://gerrit.wikimedia.org/r/#/c/165478/ > <https://gerrit.wikimedia.org/r/#/c/165478/> > https://gerrit.wikimedia.org/r/#/c/165479/ > <https://gerrit.wikimedia.org/r/#/c/165479/> > [2] https://gerrit.wikimedia.org/r/#/c/16468/ > <https://gerrit.wikimedia.org/r/#/c/16468/> > [3] https://github.com/hartman/mwEmbed/compare/jscleanup > <https://github.com/hartman/mwEmbed/compare/jscleanup> > [4] https://phabricator.wikimedia.org/P147 > <https://phabricator.wikimedia.org/P147> > > _______________________________________________ > Multimedia mailing list > multime...@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/multimedia _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
