Le 16/01/2015 07:38, Bryan Davis a écrit :
There has been a lot of talk over the last year or so of how and when to move MediaWiki to a service oriented architecture [0]. So much so that it is actually one of the a marquee topics at the upcoming Developer Summit.
<snip>
Hello,
Moving to a service oriented architecture will certainly ease Wikimedia maintenance, or at least delegate maintenance authority to independent sub teams which would be rather nice.
The monolithic approach of MediaWiki with all services / classes being tightly coupled makes the platform rather hard to build upon. It certainly lacks clear contracts between components.
Can the SOA model be supported on shared hosts or by third parties? Surely. But one has to handle the integration and release work to make it easy to install all the components and configure them. Is Wikimedia going to handle it? I doubt it.
The underlying choice is:
a) should Wikimedia keep being slowed down claiming MediaWiki is suitable for others
b) Reclaims MediaWiki has a Wiki made to create and distribute free knowledge geared toward supporting Wikipedia and others WMF projects.
I think WMF should reclaim it, take decisions and stop pretending we support third parties installation. That would mean going as far as dropping postgreSQL support since we have no use for it.
So what we might end up with:
- Wikimedia using the SOA MediaWiki with split components maintained by staff and the Wikimedia volunteers devs. Code which is of no use for the cluster is dropped which would surely ease maintainability. We can then reduce MediaWiki to a very thin middleware and eventually rewrite whatever few code is left.
- The old MediaWiki PHP based is forked and given to the community to maintain. WMF is no more involved in it and the PHP-only project live it's on life. That project could be made to remove a lot of the rather complicated code that suits mostly Wikimedia, making MediaWiki simpler and easier to adjust for small installations.
So, is it time to fork both intent? I think so.