Hi all,
the multimedia team [1] had a chat about some architectural issues with MultimediaViewer [2] today, and Robla has pointed out that we should publish such discussions on wikitech-l to make sure we do no reinvent to many wheels, so here goes. Comments pointing out all the obvious solutions we have missed are very welcome.
== Use of OOjs-UI ==
Mark experimentally implemented a panel showing share/embed links [3][4] in OOjs-UI [5]; we discussed some concerns about that. We want to avoid having to roll our own UI toolkit, and also don't want to introduce yet another third-party toolkit as the list of libraries loaded by some Wikipedia extension or other is already too long, and the look-and-feel already too fractured, so we would be happy to free-ride on another team's efforts :) On the other hand, OOjs-UI is still under development, does not have tests and has very little documentation, and the browser support is less than we would prefer. We could contribute back in those areas, but it would slow us down significantly.
In the end we felt that's not something we should decide on our own as it involves redefining the goals of the team somewhat (it was a developer-only meeting), so we left it open. (The next MultimediaViewer features which would depend heavily on a UI toolkit are a few months away, so it is not an urgent decision for us.)
== The state of unit tests ==
MultimediaViewer used to have a messy codebase; we felt at the time that it is better to have ugly tests than no tests, so we ended up with some large and convoluted tests which are hard to maintain. Since then we did a lot of refactoring but kept most of the tests, so now we have some tests which are harder to understand and more effort to maintain than the code they are testing. Also, we fixed failing tests after the refactorings, but did not check the working ones, we cannot be sure they are still testing what they are supposed to.
We discussed these issues, and decided that writing the tests was still a good decision at the time, but once we are done with the major code refactorings, we should take some time to refactor the tests as well. Many of our current tests test the implementation of a class; we should replace them with ones that test the specification.
== Plugin architecture ==
We had plans to create some sort of plugin system so that gadgets can extend the functionality of MultimediaViewer [6]; we discussed whether that should be an open model where it is possible to alter the behavior of any component (think Symfony2 or Firefox) and plugins are not limited in their functionality, or a closed model where there are a limited number of junction points where gadgets can influence behavior (think MediaWiki hook system, just much more limited).
The open model seems more in line with Wikimedia philosophy, and might actually be easier to implement (most of it is just good architecture like services or dependency injection which would make sense even if we did not want plugins); on the other hand it would mean a lot of gadgets break every time we change things, and some possibly do even if we don't. Also, many the community seems to have much lower tolerance for breakage in WMF-maintained tools breaking than in community-maintained tools, and most people probably wouldn't make the distinction between MultimediaViewer breaking because it is buggy and it breaking because a gadget interacting with it is buggy, so giving plugins enough freedom to break it might be inviting conflict. Some sort of hook system (with try-catch blocks, strict validation etc) would be much more stable, and it would probably require less technical expertise to use, but it could prevent many potential uses, and forces us to make more assumptions about what kind of plugins people would write.
Decision: go with the closed model; reach out for potential plugin writers and collect requirements; do not guess, only add plugin functionality where it is actually requested by someone. In general try not to spend too much effort on it, having a useful plugin system by the time MultimediaViewer is deployed publicly is probably too ambitious a goal.
[1] https://www.mediawiki.org/wiki/Multimedia [2] https://www.mediawiki.org/wiki/Extension:MultimediaViewer [3] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/147 [4] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/148 [5] https://www.mediawiki.org/wiki/OOjs_UI [6] https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/168