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