Hi!
The problem there is that the PHP implementation is
likely to code-rot,
unless we create really good unit tests that actually run for it.
With service architecture, there should be a test suite running against
the service and verifying the compliance with the API definition. So if
the PHP implementation passes that, it should be fine.
It would be less bad if the focus were on
librarization and daemonization
(and improvement) of the existing PHP code so both methods could share a
majority of the code base, rather than rewriting things from scratch in an
entirely different language.
I think language is secondary here to other concerns. I.e. if the scale
requirements require implementing something that is best written in
language X, then requiring it to be all in PHP may just not be practical
for the scale.
That becomes a hazard when other stuff starts to
depend on the non-reduced
feature set.
True, but I think there could still be minimal API and extended API.
E.g. search engine could support just word match search or advanced
expressions, or a database may be transactional with high levels or
reliability or non-transactional storage with minimal guarantees. Of
course, that means some functions would not be available everywhere -
but I don't see a good way to avoid it when the requirements diverge.
--
Stas Malyshev
smalyshev(a)wikimedia.org