I just want a MediaWiki API 2.0 :) Ryan Kaldari
On 12/6/11 1:55 PM, Dan Nessett wrote: > 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. > _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
