This set of proposals as written sound reasonable. (: Pine On Feb 15, 2015 6:47 PM, "Rob Lanphier" <[email protected]> wrote:
> 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_presentation_vs_data_manipulation_line > > 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_public_vs_private_line > > 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 > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
