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/kaltur…
<http://knowledge.kaltura.com/sites/default/files/styles/large/public/kaltura-player-toolkit.png>
[2]
http://kgit.html5video.org/pulls/1194/modules/KalturaSupport/tests/StandAlo…
<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_ml(a)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
Multimedia(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/multimedia 