Hi everyone,
There has been a lot of talk over the past year or so about SOA and
what it means for MediaWiki. What I've taken from the conversation is
the following:
1. There is a general desire for us to separate user interface code
from data manipulation code. This is mainly in service of making
alternative user interfaces simpler and cleaner (e.g. mobile web,
mobile apps, print, offline). The developers that are consumers of
said systems (i.e. user interface developers) probably don't care so
much what goes on inside the data manipulation sausage factory, so
long as the APIs used to access our data are well-defined and easy to
use. It may be one data manipulation service, it may be 100 tiny
little services with a brokering layer, but as long as there's a clean
split, all is well. I've created an RFC which basically spells this
out:
https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_pre…
Note that there is nothing terribly creative about this idea, and
*that is the point*. With this RFC, let's document which aspects are
utterly uncontroversial so that we can make clear the urgency to come
to consensus on more specific proposals, such as Trevor and Timo's
proposal to redo the skin system[1]
2. Within the larger data manipulation area, there is also potential
for another split between public information (e.g. pages on public
wikis, the vast majority of old revisions, etc) and private
information (e.g. pages on private wikis, revdel'ed revisions,
CheckUser information). With public information, we can choose
technologies that optimize for replication and data delivery (speed
and volume). With private information, we can lock things down more,
possibly losing efficiency in exchange for greater security. Since
private information will presumably be accessed less frequently in
most cases, and the limited cases where high frequency access is
needed (e.g. authn/authz) typically don't involve a lot of data flow,
we can generally make different design decisions. I've also created
an RFC that spells this out too:
https://www.mediawiki.org/wiki/Requests_for_comment/Service_split_along_pub…
These RFCs are both admittedly vague, somewhat on purpose. It's
useful to agree on a general direction before getting down in the
weeds on specific proposals. Proposal #1, other than the lack of
specificity, is hopefully completely uncontroversial, and thus (maybe
with a *little* fleshing out) could sail through the process.
Proposal #2 may be a bit more controversial, but something that is
worth some discussion.
For the specifics on these proposals, the best place to discuss these
is the talk page. If/when the conversation dies out there (or if it
never really starts), I'll summarize on this list.
If there are other sensible places for cleaner fissures in the system,
please document where you think they should go. Even if the fissures
we define are not boundaries between hardware clusters, but instead
just library boundaries, that's still useful to mark where those lines
should go.
Rob
[1]
https://www.mediawiki.org/wiki/Requests_for_comment/Redo_skin_framework