This is a (admittedly long and elaborate) question, not a proposal. I ask it in order to learn whether anyone has given it or something like it some thought.
Has anyone thought of creating MW 2.0? I mean by this, completely rewriting the application in a way that may make it incompatible with MW 1.x.y.
Pros ----
* Improving the application architecture * Utilizing more client side resources, thereby reducing the server side resource requirements. * Clean up and improve existing services.
Cons ----
* Rewrites of major applications normally fail because they become overly ambitious.
Some possible ways MW 2.0 might improve MW 1.x.y
Change the parser -----------------
* Get rid of mediawiki markup and move to html with embedded macros that are processed client side. * Move extension processing client side. * Replace templates with a cleaner macro-based language (but, KISS).
Pros ----
* Reduce server side resource requirements, thereby reducing server side costs. Server side becomes mostly database manipulation. * Make use of the far larger aggregate resources available on client side (many more client machines than server machines). * With macro processing client side, debates about enhancements to parser extensions that require more processing shift to looking at client side. * Allows development of a parser driven by well-defined grammar.
Cons ----
* Unclear whether it is possible to move all or most parser processing to client side. * Would need a (probably large and complex) transition application that translates mediawiki markup into new grammar. * Since not all clients may have the resources to expand macros and do other client side processing in a timely manner, may need to provide server side surrogate processing based on either user selectable (e.g., preferences) choice or automatic discovery. * Need to select client side processing engine (e.g., Javascript, Java), which may lead to major developer fighting.
Clean up security architecture ------------------------------
* Support per page permissions, ala' Unix file system model. * Integrate authentication with emerging global services (e.g., OpenID) without use of extensions. * Move group membership definition out of LocalSettings into database table.
Pros ----
* Chance to think through security requirements and craft clean solution. * Offload most authentication processing and login data protection to service providers that more sharply focus on its requirements. * Some customers have expressed interest in per page permissions.
Cons ----
* Changing security architectures is a notoriously difficult objective. Most attempts lead to bloated solutions that never work in practice. * Some developers oppose per page permissions. * Would need to develop WMF standards that authentication providers must meet before accepting them for WMF project login.
This is sufficient to illustrate the direction of my curiosity, but there are other things that MW 2.0 could do that might be discussed, such as:
* Change the page history model. When page is flagged stable, subsequent page changes occur to new draft page. Provide link to draft page on stable page. * Think through how to support multiple db backends so application development doesn't continually break this support.