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.
--
Antoine "hashar" Musso