Hoi,

On the Wikidata roadmap it says that Commons will be targeted for inclusion in the second half of 2014. This will have a big impact on Commons. Consequently it will have a big impact on the things that you are discussing. Chances are that much of what you come up with now will be obsolete in a few months time or even worse make the development of the inclusion of Wikidata into Commons even harder.

I find it odd that Wikidata is not mentioned at all in this overview. Thanks, GerardM

On 7 March 2014 04:06, Gergo Tisza gtisza@wikimedia.org wrote:

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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Hey,

This overview seems quite reasonable to me until this point:

on the other hand it [using ie dependency injection] would mean a lot of

gadgets break every time we change things, and some possibly do even if we don't.

I am unsure how you are reaching that conclusion.

Dependency Injection, and more generally speaking Inversion of Control, is an often useful approach in creating cohesive code with low coupling. However in itself it does not magically make your architecture and code quality good. You can still create low quality code and a bad architecture when using Dependency Injection (granted, it's easier to do so when not using DI).

If gadgets break whenever you change something, you are suffering from whats called fragility. The main cause for this is coupling that should not be there. On an architecture level this means there is something wrong with your boundaries. That is the first thing I'd be scrutinizing in your situation.

Some sort of hook system (with try-catch blocks, strict

validation etc) would be much more stable

I'm not sure either approach is inherently more stable. Stability depends a lot on how you are implementing it. The main thing to hold in mind here for either approach is to be careful with what you expose. Narrow well defined interfaces are typically the way you want to go. When exposing to much, one ends up in a situation where flexibility and stability are at odds - ie either you cannot make a certain change in your code, or you need to break the public interface.

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.

What I like about this is that you are not randomly adding a bunch of hooks. Each hook decreases your flexibility a tiny bit and each hook is additional maintenance cost. If you introduce them on an as-needed basis and make sure your hook has a nice interface and well defined goal, then you are well on your way to nicely implementing this.

This approach is however not disjoint with Inversion of Control and good architecture, which you apparently agree with:

most of it is just good architecture like

services or dependency injection which would make sense even if we did not want plugins

So I do hope you will also be pursuing that road.

It is not clear to me from your email that you are holding the difference between libraries and applications into account, so I'll briefly explain.

Either a component is reusable or not, having a component with reusable and non-reusable code in it, and trying to reuse that reusable code from it is bad practice. Reusable code typically ends up in libraries. These libraries have no state. Non-reusable components, such as applications and extensions, typically do have their own state. If you want some code to be truly reusable, going with the library approach, as the Symfony Components are doing, is almost certainly the right approach. And indeed, this to is merely generally good practice one should probably follow even when not having the explicit goal to make something reusable.

The problem with having this supposedly reusable functionality in one component with state that cannot be used as library is that it forces as users to work together. It is like a global variable or a static class. When modifying the thing (ie via a hook), one needs to be careful to not do this in a way that breaks the other users. When at some point two different users have constraints for the state that conflict, you have a problem. At that point you are faced with the choice between painful refactoring or creating an even bigger mess.

Cheers

-- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3