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.
--
-- Dan Nessett