Re: [Wikitech-l] Multimedia team architecture update
On Fri, Mar 7, 2014 at 3:27 AM, Gerard Meijssen gerard.meijs...@gmail.comwrote: When Commons gets the Wikidata treatment, almost everything that has to do with meta data will gain wikidata statements on the Wikidata item that reflects a media file (sound photo movie no matter). When items refer to Creators or Institutions they will refer to Wikidata proper. MultimediaViewer is concerned with displaying images in fullscreen and showing associated metadata; the first is not affected by Wikidata at all, the second only inasmuch as metadata coming from Wikidata will be essentially different from metadata coming from other sources. As far as I can see, it won't. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
Hoi, Your assumption is that the metadata from Wikidata will be essentially the same. It is not. Because the metadata will be essentially different, I ask for attention. At this moment in time all the metadata is essentially English. This will be no longer the case with Wikidata. The data that is provided can be in any language. In future there will no longer be a guarantee that there will be information in English. Also, with Wikidata, the one suggestion that has the most promise for helping FIND media files is that they will be tagged. This will probably make categories less relevant. It is quite funny in my opinion. You assume that business will be as usual and consequently show no interest in how Wikidata can be a game changer. At this time Commons is the repository where everyone can contribute. People have a hard time finding anything. How do you find a picture from Batavia from 1930 / 1940 ? How do you search for this in Dutch ? The Wikidata treatment of Commons makes it possible to find them. As metadata like GPS info will associated with a subject, a photo with GPS information may be the source of providing GPS information to subjects. As yet another picture of the Borobodur arrives at Commons, the GPS info may suggest that the label in Zulu is (however Borobodur is writen in Zulu), this enables the suggestion to add the label for Borobodur in Zulu. When people are looking at pictures, we can ask them to add the missing labels in their language. Wikidata will be a game changer for the usability of Commons. It enables FINDING media files. At this time I do not even bother it takes too much effort. IMHO all this is exactly what a plan about an architecture update should be about Thanks, GerardM On 9 March 2014 05:49, Gergo Tisza gti...@wikimedia.org wrote: On Fri, Mar 7, 2014 at 3:27 AM, Gerard Meijssen gerard.meijs...@gmail.comwrote: When Commons gets the Wikidata treatment, almost everything that has to do with meta data will gain wikidata statements on the Wikidata item that reflects a media file (sound photo movie no matter). When items refer to Creators or Institutions they will refer to Wikidata proper. MultimediaViewer is concerned with displaying images in fullscreen and showing associated metadata; the first is not affected by Wikidata at all, the second only inasmuch as metadata coming from Wikidata will be essentially different from metadata coming from other sources. As far as I can see, it won't. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
On Mar 9, 2014 1:35 AM, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, Your assumption is that the metadata from Wikidata will be essentially the same. It is not. Because the metadata will be essentially different, I ask for attention. At this moment in time all the metadata is essentially English. I havent been following the most recent mmv developments, but thats not my impression. Even if that is the case it wouldnt change that much. This will be no longer the case with Wikidata. The data that is provided can be in any language. In future there will no longer be a guarantee that there will be information in English. Lots of files dont have en descriptions currently. Also, with Wikidata, the one suggestion that has the most promise for helping FIND media files is that they will be tagged. This will probably make categories less relevant. Meh, tagging and categories are essentially the same thing with different social conventions. Even if tagging starts happening on commons i dont see anything other than a superficial affect on multimediaviewer. It is quite funny in my opinion. You assume that business will be as usual and consequently show no interest in how Wikidata can be a game changer. At this time Commons is the repository where everyone can contribute. People have a hard time finding anything. How do you find a picture from Batavia from 1930 / 1940 ? How do you search for this in Dutch ? The Wikidata treatment of Commons makes it possible to find them. Yes, but i dont see that being relavent to multimedia viewer. At least not architecturally. It might be able to take advantage of this, but it wouldnt require architecture changes. As metadata like GPS info will associated with a subject, a photo with GPS information may be the source of providing GPS information to subjects. As yet another picture of the Borobodur arrives at Commons, the GPS info may suggest that the label in Zulu is (however Borobodur is writen in Zulu), this enables the suggestion to add the label for Borobodur in Zulu. We already store gps info in queryable form for both wikipedia articles (subjects) and pictures. And we have for at least a year. Somebody could make something to suggest categories based on gps right now if they wanted. I fail to see relavence to multimedia viewer. When people are looking at pictures, we can ask them to add the missing labels in their language. Wikidata will make this easier. Somebody could do this with hacky js right now if they wanted. Wikidata will be a game changer for the usability of Commons. It enables FINDING media files. At this time I do not even bother it takes too much effort. IMHO all this is exactly what a plan about an architecture update should be about I think you are talking about a different type of architecture. The code structure of multimedia viewer is the architecture in question. The big picture structure of commons is an entirely different conversation. Wikidata may be a game changer to commons. I doubt it will have a significant affect on the code arcitecture of the multimedia viewer project. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
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 gti...@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]
Re: [Wikitech-l] Multimedia team architecture update
On Fri, 2014-03-07 at 11:50 +0100, Gerard Meijssen wrote: 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. Please elaborate where / in which specific areas you would have expected to see Wikidata being mentioned in Gergo's overview, as I cannot interpret the consequently in your statement yet. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
Hoi, When Commons gets the Wikidata treatment, almost everything that has to do with meta data will gain wikidata statements on the Wikidata item that reflects a media file (sound photo movie no matter). When items refer to Creators or Institutions they will refer to Wikidata proper. This will replace much if not most of how information is stored about media files. Pretty much almost everything will be impacted and that is what I expect to be reflected in considerations now because the alternative is that much of it will need to be revisited on a massive scale. Thanks, GerardM On 7 March 2014 12:19, Andre Klapper aklap...@wikimedia.org wrote: On Fri, 2014-03-07 at 11:50 +0100, Gerard Meijssen wrote: 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. Please elaborate where / in which specific areas you would have expected to see Wikidata being mentioned in Gergo's overview, as I cannot interpret the consequently in your statement yet. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
On Thu, Mar 6, 2014 at 8:06 PM, Gergo Tisza gti...@wikimedia.org wrote: Hi all, == The state of unit tests == 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. This process is something that I think would be of great interest to a variety of teams: * When to throw away old tests * When to create new tests (TDD style, before writing the code that satisfies the test?) * When to refactor existing tests * At what point do you make these decisions? I'd like to encourage you to discuss your approaches along these lines, because I think it would be of great interest across all the WMF dev teams. -Chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
On 7 March 2014 15:13, Chris McMahon cmcma...@wikimedia.org wrote: This process is something that I think would be of great interest to a variety of teams: * When to throw away old tests * When to create new tests (TDD style, before writing the code that satisfies the test?) * When to refactor existing tests * At what point do you make these decisions? I'd like to encourage you to discuss your approaches along these lines, because I think it would be of great interest across all the WMF dev teams. This essay has been going around. There's a lot to it IMO. http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf tl;dr unit test is another word for assert. Now, *acceptance* tests ... - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
Also see Michael Feathers' response to Coplien via Twitter: http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html / https://twitter.com/mfeathers/statuses/441598005515669504 On Fri, Mar 7, 2014 at 9:53 AM, David Gerard dger...@gmail.com wrote: On 7 March 2014 15:13, Chris McMahon cmcma...@wikimedia.org wrote: This process is something that I think would be of great interest to a variety of teams: * When to throw away old tests * When to create new tests (TDD style, before writing the code that satisfies the test?) * When to refactor existing tests * At what point do you make these decisions? I'd like to encourage you to discuss your approaches along these lines, because I think it would be of great interest across all the WMF dev teams. This essay has been going around. There's a lot to it IMO. http://www.rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf tl;dr unit test is another word for assert. Now, *acceptance* tests ... - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
+1 If this helps to get it on the list Am 07.03.2014 12:28 schrieb Gerard Meijssen gerard.meijs...@gmail.com: Hoi, When Commons gets the Wikidata treatment, almost everything that has to do with meta data will gain wikidata statements on the Wikidata item that reflects a media file (sound photo movie no matter). When items refer to Creators or Institutions they will refer to Wikidata proper. This will replace much if not most of how information is stored about media files. Pretty much almost everything will be impacted and that is what I expect to be reflected in considerations now because the alternative is that much of it will need to be revisited on a massive scale. Thanks, GerardM On 7 March 2014 12:19, Andre Klapper aklap...@wikimedia.org wrote: On Fri, 2014-03-07 at 11:50 +0100, Gerard Meijssen wrote: 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. Please elaborate where / in which specific areas you would have expected to see Wikidata being mentioned in Gergo's overview, as I cannot interpret the consequently in your statement yet. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
On 7 March 2014 17:15, Chris McMahon cmcma...@wikimedia.org wrote: Also see Michael Feathers' response to Coplien via Twitter: http://michaelfeathers.typepad.com/michael_feathers_blog/2008/06/the-flawed-theo.html / https://twitter.com/mfeathers/statuses/441598005515669504 With which I and the author of the PDF would no doubt fully concur. tl;dr you *still* can't Taylorise knowing what the heck you're doing :-) (It caught my attention because my day job is doing the painful shift from pottering about to a more formal Scrum process. There's a lot of seriously smart people there and they are indeed hacking through the encrustations of process-as-talisman, so that's good ...) - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Multimedia team architecture update
On 7 mrt. 2014, at 12:27, Gerard Meijssen gerard.meijs...@gmail.com wrote: Hoi, When Commons gets the Wikidata treatment, almost everything that has to do with meta data will gain wikidata statements on the Wikidata item that reflects a media file (sound photo movie no matter). When items refer to Creators or Institutions they will refer to Wikidata proper. This will replace much if not most of how information is stored about media files. Pretty much almost everything will be impacted and that is what I expect to be reflected in considerations now because the alternative is that much of it will need to be revisited on a massive scale. Thanks, GerardM This is not mutual exclusive. 1: You said it much, if not most Neither much, nor most == all 2: The output api is very important here, and the output API won't/doesn't really care about where the data is coming from. 3: Much of this has to do with data entry and creating links. Wether you couple text, wikitext or an ID, it doesn't really matter that much. you still need the software to make it accessible, usable and understandable during the upload process or the 'maintenance' process. The view != data model 4: You should not make too much interteam commitments if you aren't directly interacting. Be agile, change plans as you go to find the best solution if needed. Be informed sure, but don't wait. My point is YES, wikidata is important and it overlaps with some aspects of these goals, but it's just one part of the userstory, and it's the part the general user will care least about, and the part that is probably easiest to replace (since it's backend facing). DJ On 7 March 2014 12:19, Andre Klapper aklap...@wikimedia.org wrote: On Fri, 2014-03-07 at 11:50 +0100, Gerard Meijssen wrote: 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. Please elaborate where / in which specific areas you would have expected to see Wikidata being mentioned in Gergo's overview, as I cannot interpret the consequently in your statement yet. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l signature.asc Description: Message signed with OpenPGP using GPGMail ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Multimedia team architecture update
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
