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_pres...
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_publ...
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