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.
On Wed, 07 Dec 2011 07:59:26 +1000, K. Peachey wrote:
Thanks. I have moved my comments to that page's discussion.
On 07/12/11 08:55, 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.
[...]
- 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).
Keeping the same name ("MediaWiki") implies some level of compatibility with older versions of the same software. If you abandon existing installations and their needs altogether, then it makes sense to choose a new project name, so that the 1.x code can continue to be maintained and improved without causing user confusion.
I think MediaWiki 2.0 should just be a renumbering, like Linux 2.6 -> 3.0, rather than any kind of backwards compatibility break.
-- Tim Starling
On Tue, Dec 6, 2011 at 5:26 PM, Tim Starling tstarling@wikimedia.org wrote:
I think MediaWiki 2.0 should just be a renumbering, like Linux 2.6 -> 3.0, rather than any kind of backwards compatibility break.
+1. It can be a big release, but it doesn't have to be a back-compat-breaking one.
-Chad
On Wed, 07 Dec 2011 09:26:50 +1100, Tim Starling wrote:
On 07/12/11 08:55, 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.
[...]
- 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).
Keeping the same name ("MediaWiki") implies some level of compatibility with older versions of the same software. If you abandon existing installations and their needs altogether, then it makes sense to choose a new project name, so that the 1.x code can continue to be maintained and improved without causing user confusion.
I think MediaWiki 2.0 should just be a renumbering, like Linux 2.6 -> 3.0, rather than any kind of backwards compatibility break.
-- Tim Starling
OK. Call it something else. The motivation for my question is getting server costs under control. Moving as much processing as possible client side is one way to achieve this. Cleaning up the security architecture may be overly ambitious, but a rewrite would provide the opportunity to take a rational look at MW's vulnerabilities and security services.
I don't know where WMF is on the cost question, but we would benefit from reducing our hosting costs.
I don't know where WMF is on the cost question, but we would benefit from reducing our hosting costs.
Hosting costs are really cheap whenever i compare us to anyone else. What's much harder is getting new developers up and running. If we could reduce the complexity and increase the consistency of our code then we could release new features much faster and have more volunteers involved.
--tomasz
On 07/12/11 09:50, Dan Nessett wrote:
OK. Call it something else. The motivation for my question is getting server costs under control. Moving as much processing as possible client side is one way to achieve this. Cleaning up the security architecture may be overly ambitious, but a rewrite would provide the opportunity to take a rational look at MW's vulnerabilities and security services.
I don't know where WMF is on the cost question, but we would benefit from reducing our hosting costs.
WMF's hosting costs are pretty well under control. We have two parser CPU reduction features on our roadmap, but the main justification for doing them is to reduce latency, rather than cost, thus providing a better user experience. If both of them are fully utilised, we can probably reduce average parse time by a factor of 10.
By "we" do you mean Citizendium? How many servers do you have?
-- Tim Starling
On Wed, 07 Dec 2011 12:15:41 +1100, Tim Starling wrote:
On 07/12/11 09:50, Dan Nessett wrote:
OK. Call it something else. The motivation for my question is getting server costs under control. Moving as much processing as possible client side is one way to achieve this. Cleaning up the security architecture may be overly ambitious, but a rewrite would provide the opportunity to take a rational look at MW's vulnerabilities and security services.
I don't know where WMF is on the cost question, but we would benefit from reducing our hosting costs.
WMF's hosting costs are pretty well under control. We have two parser CPU reduction features on our roadmap, but the main justification for doing them is to reduce latency, rather than cost, thus providing a better user experience. If both of them are fully utilised, we can probably reduce average parse time by a factor of 10.
By "we" do you mean Citizendium?
Yes.
How many servers do you have?
3. It would help to get it down to 2.
I assume my comments apply to many other small wikis that use MW as well. Most operate on a shoe string budget.
On 07/12/11 12:34, Dan Nessett wrote:
On Wed, 07 Dec 2011 12:15:41 +1100, Tim Starling wrote:
How many servers do you have?
- It would help to get it down to 2.
I assume my comments apply to many other small wikis that use MW as well. Most operate on a shoe string budget.
You should try running MediaWiki on HipHop. See
http://www.mediawiki.org/wiki/HipHop
It's not possible to pay developers to rewrite MediaWiki for less than what it would cost to buy a server. But maybe getting a particular MW installation to run on HipHop with a reduced feature set would be in the same order of magnitude of cost.
-- Tim Starling
* Tim Starling tstarling@wikimedia.org [Wed, 07 Dec 2011 12:54:22 +1100]:
On 07/12/11 12:34, Dan Nessett wrote:
On Wed, 07 Dec 2011 12:15:41 +1100, Tim Starling wrote:
How many servers do you have?
- It would help to get it down to 2.
I assume my comments apply to many other small wikis that use MW as
well.
Most operate on a shoe string budget.
You should try running MediaWiki on HipHop. See
http://www.mediawiki.org/wiki/HipHop
It's not possible to pay developers to rewrite MediaWiki for less than what it would cost to buy a server. But maybe getting a particular MW installation to run on HipHop with a reduced feature set would be in the same order of magnitude of cost.
-- Tim Starling
An easier and probably more exotic-extension-compatible way is to use upcoming PHP 5.4, they promised faster execution and smaller memory footprint comparing to PHP 5.3. Dmitriy
On Wed, 07 Dec 2011 12:54:22 +1100, Tim Starling wrote:
On 07/12/11 12:34, Dan Nessett wrote:
On Wed, 07 Dec 2011 12:15:41 +1100, Tim Starling wrote:
How many servers do you have?
- It would help to get it down to 2.
I assume my comments apply to many other small wikis that use MW as well. Most operate on a shoe string budget.
You should try running MediaWiki on HipHop. See
http://www.mediawiki.org/wiki/HipHop
It's not possible to pay developers to rewrite MediaWiki for less than what it would cost to buy a server. But maybe getting a particular MW installation to run on HipHop with a reduced feature set would be in the same order of magnitude of cost.
-- Tim Starling
Are there any production wikis running MW over HipHop?
On 08/12/11 05:45, Dan Nessett wrote:
On Wed, 07 Dec 2011 12:54:22 +1100, Tim Starling wrote:
On 07/12/11 12:34, Dan Nessett wrote:
On Wed, 07 Dec 2011 12:15:41 +1100, Tim Starling wrote:
How many servers do you have?
- It would help to get it down to 2.
I assume my comments apply to many other small wikis that use MW as well. Most operate on a shoe string budget.
You should try running MediaWiki on HipHop. See
http://www.mediawiki.org/wiki/HipHop
It's not possible to pay developers to rewrite MediaWiki for less than what it would cost to buy a server. But maybe getting a particular MW installation to run on HipHop with a reduced feature set would be in the same order of magnitude of cost.
-- Tim Starling
Are there any production wikis running MW over HipHop?
No. There are very few test installations, let alone production installations. But isn't it exciting to break new ground?
-- Tim Starling
I think that the current version numbering system is confusing, incremental version increases from 1.15 to 1.16 to 1.17 to 1.18, etc suggest to most people minor changes with no compatibility implications. This is not the case with MW. The Chrome version numbering is the other extreme, releasing every 6 weeks a major version increment. In the end I think that a version system should give an idea how much has changed under the hood. just my 2 cents. Diederik
On Thu, Dec 8, 2011 at 4:19 AM, Tim Starling tstarling@wikimedia.orgwrote:
On 08/12/11 05:45, Dan Nessett wrote:
On Wed, 07 Dec 2011 12:54:22 +1100, Tim Starling wrote:
On 07/12/11 12:34, Dan Nessett wrote:
On Wed, 07 Dec 2011 12:15:41 +1100, Tim Starling wrote:
How many servers do you have?
- It would help to get it down to 2.
I assume my comments apply to many other small wikis that use MW as well. Most operate on a shoe string budget.
You should try running MediaWiki on HipHop. See
http://www.mediawiki.org/wiki/HipHop
It's not possible to pay developers to rewrite MediaWiki for less than what it would cost to buy a server. But maybe getting a particular MW installation to run on HipHop with a reduced feature set would be in the same order of magnitude of cost.
-- Tim Starling
Are there any production wikis running MW over HipHop?
No. There are very few test installations, let alone production installations. But isn't it exciting to break new ground?
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
I'd like to suggest something Neil has suggested before...
- Trevor
On Thu, Dec 8, 2011 at 7:31 AM, Diederik van Liere dvanliere@gmail.comwrote:
I think that the current version numbering system is confusing, incremental version increases from 1.15 to 1.16 to 1.17 to 1.18, etc suggest to most people minor changes with no compatibility implications. This is not the case with MW. The Chrome version numbering is the other extreme, releasing every 6 weeks a major version increment. In the end I think that a version system should give an idea how much has changed under the hood. just my 2 cents. Diederik
On Thu, Dec 8, 2011 at 4:19 AM, Tim Starling <tstarling@wikimedia.org
wrote:
On 08/12/11 05:45, Dan Nessett wrote:
On Wed, 07 Dec 2011 12:54:22 +1100, Tim Starling wrote:
On 07/12/11 12:34, Dan Nessett wrote:
On Wed, 07 Dec 2011 12:15:41 +1100, Tim Starling wrote:
How many servers do you have?
- It would help to get it down to 2.
I assume my comments apply to many other small wikis that use MW as well. Most operate on a shoe string budget.
You should try running MediaWiki on HipHop. See
http://www.mediawiki.org/wiki/HipHop
It's not possible to pay developers to rewrite MediaWiki for less than what it would cost to buy a server. But maybe getting a particular MW installation to run on HipHop with a reduced feature set would be in
the
same order of magnitude of cost.
-- Tim Starling
Are there any production wikis running MW over HipHop?
No. There are very few test installations, let alone production installations. But isn't it exciting to break new ground?
-- Tim Starling
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 09/12/11 08:44, Trevor Parscal wrote:
I'd like to suggest something Neil has suggested before...
Maybe we could have an "API version" which corresponds to the rules given there, like the API version in PHP.
Our major versions (1.18 etc.) correspond to branches, and so we sometimes have to introduce non-backwards-compatible changes in minor releases in order to fix security vulnerabilities. If we only applied such security changes to new major releases, applying them would be tied to performing a major and potentially complex upgrade, which would slow down the mitigation process significantly.
-- Tim Starling
I wrote:
On 09/12/11 08:44, Trevor Parscal wrote:
I'd like to suggest something Neil has suggested before...
Maybe we could have an "API version" which corresponds to the rules given there, like the API version in PHP.
Our major versions (1.18 etc.) correspond to branches, and so we sometimes have to introduce non-backwards-compatible changes in minor releases in order to fix security vulnerabilities. If we only applied such security changes to new major releases, applying them would be tied to performing a major and potentially complex upgrade, which would slow down the mitigation process significantly.
Actually, come to think of it, PHP is probably a bad example for this. I told the PHP devs about a security vulnerability (a dangling pointer) in PHP 4, two years before the branch end-of-life, and they said they couldn't fix it in that branch because it would break the interface.
http://thread.gmane.org/gmane.comp.php.devel/34503
-- Tim Starling
On 7 December 2011 02:34, Dan Nessett dnessett@yahoo.com wrote:
- It would help to get it down to 2.
I assume my comments apply to many other small wikis that use MW as well. Most operate on a shoe string budget.
Tried a caching system? My wiki gets 3000+ visitors a day (I don't know how many Citizendium gets). But my server (costing 49EUR a month) can easily manage that plus several other websites including running some game servers as well. All I am saying is; it may be too easy to blame it on MW alone.
----- Original Message -----
From: "Tim Starling" tstarling@wikimedia.org
I think MediaWiki 2.0 should just be a renumbering, like Linux 2.6 -> 3.0, rather than any kind of backwards compatibility break.
I disagree. (You knew that was coming, right? :-)
A major version number change *necessarily implies* an API compatibility break of some type, or a major rewrite. In the case of 2.6 to 3.0 of the kernel, as someone pointed out to me, the change was *in the numbering protocol itself*; prior to 3.0, odd numbers were dev; that's no longer true, which makes it a suitable break to bump the major version number.
Cheers, -- jra
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.
In that case why not use some other wiki software? There are quite a few. See <//http://www.wikimatrix.org/%3E.
If you're willing to jettison all existing wiki data I'm not sure I would recommend MediaWiki for a fresh start. I would in many cases, but not all.
In any case, the WMF already have people working on a new parser, and a new GUI editor. If both of those projects reach fruition I would call that 2.0-worthy right there. Also, the new parser should provide us with some means to transition to a different wiki syntax if we think it's a good idea.
If we wanted to *really* get radical, then we'd think about changing the storage model too, but you might as well rename it by that point.
On Tue, 06 Dec 2011 16:18:03 -0800, Neil Kandalgaonkar neilk@wikimedia.org wrote:
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.
In that case why not use some other wiki software? There are quite a few. See <//http://www.wikimatrix.org/%3E.
If you're willing to jettison all existing wiki data I'm not sure I would recommend MediaWiki for a fresh start. I would in many cases, but not all.
In any case, the WMF already have people working on a new parser, and a new GUI editor. If both of those projects reach fruition I would call that 2.0-worthy right there. Also, the new parser should provide us with some means to transition to a different wiki syntax if we think it's a good idea.
If we wanted to *really* get radical, then we'd think about changing the storage model too, but you might as well rename it by that point.
Title, User, PageOutput, and Skin rewrites not radical enough for a 2.0?
On 12/6/11 4:45 PM, Daniel Friesen wrote:
Title, User, PageOutput, and Skin rewrites not radical enough for a 2.0?
Nobody but MediaWiki developers really cared about the details of the Title rewrite. True, it might help users in ways they don't know about. But I think 2.x is supposed to be a signal to others that they should pay attention -- distributors, or those that offer MediaWiki as a service, or end users.
Similarly, the Semantic Versioning standard (http://semver.org/) says that 2.0 == substantial API incompatibility. I would bet that the parser rewrite is going to do that at least to some extensions. And if it also means that other wiki syntaxes become possible, then end users and bots will have to modify how they interact with wiki content.
I assume the CC to me on the message below was a courtesy. However, I would like to comment on one point in Neil's message. I was not thinking about an application rewrite that allows projects "to jettison all existing wiki data." That would make no sense for us. We would need a way to convert the wiki data from the old format (i.e., mediawiki markup) to the new.
Dan Nessett
________________________________ From: Neil Kandalgaonkar neilk@wikimedia.org To: Wikimedia developers wikitech-l@lists.wikimedia.org Cc: Dan Nessett dnessett@yahoo.com Sent: Tuesday, December 6, 2011 4:18 PM Subject: Re: [Wikitech-l] Mediawiki 2.0
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.
In that case why not use some other wiki software? There are quite a few. See <//http://www.wikimatrix.org/%3E.
If you're willing to jettison all existing wiki data I'm not sure I would recommend MediaWiki for a fresh start. I would in many cases, but not all.
In any case, the WMF already have people working on a new parser, and a new GUI editor. If both of those projects reach fruition I would call that 2.0-worthy right there. Also, the new parser should provide us with some means to transition to a different wiki syntax if we think it's a good idea.
If we wanted to *really* get radical, then we'd think about changing the storage model too, but you might as well rename it by that point.
-- Neil Kandalgaonkar |) neilk@wikimedia.org
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.
The hype of "2.0" aside, is there a guideline for what should constitute a major version number change?
It looks like we are doing something like: Major.Minor.Release
1.18 = Major: 1, Minor: 18, (alpha|beta|etc.)
I'm just curious what people think would constitue a major version. We've certainly had major rewrites of systems in the past that didn't seem to justify a version bump. Is there anything wrong with having version 1.249? Is there a practical reason for bumping the version at some point (like when the minor version hits tripple digits)?
Also, a rewrite of MediaWiki should for sure be done in Node.js :)
- Trevor
On Tue, Dec 6, 2011 at 5:16 PM, Ryan Kaldari rkaldari@wikimedia.org wrote:
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 Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
* Trevor Parscal tparscal@wikimedia.org [Tue, 6 Dec 2011 17:21:43 -0800]:
The hype of "2.0" aside, is there a guideline for what should
constitute
a major version number change?
It looks like we are doing something like: Major.Minor.Release
1.18 = Major: 1, Minor: 18, (alpha|beta|etc.)
I'm just curious what people think would constitue a major version. We've certainly had major rewrites of systems in the past that didn't seem
to
justify a version bump. Is there anything wrong with having version 1.249? Is there a practical reason for bumping the version at some point
(like
when the minor version hits tripple digits)?
Also, a rewrite of MediaWiki should for sure be done in Node.js :)
- Trevor
Is Javascript really that good? Some people dislike prototypical inheritance, it seems that jQuery prefers to use wrappers instead (that's a kind of suboptimal architecture). Also, Google had some complains about Javascript flaws (for example primitive types don't allow high performance available in Java / C#), suggesting to replace it with something else.. Although having common clientside / serverside codebase is nice thing, for sure. And there's nothing more widespread than Javascript at client side. Also, it's object side is strong (something like Lisp with C-syntax), however it does not have generics, named parameters etc.. Dmitriy
On 07.12.2011 13:33, Dmitriy Sintsov wrote:
- Trevor Parscaltparscal@wikimedia.org [Tue, 6 Dec 2011 17:21:43
-0800]:
The hype of "2.0" aside, is there a guideline for what should
constitute
a major version number change?
It looks like we are doing something like: Major.Minor.Release
1.18 = Major: 1, Minor: 18, (alpha|beta|etc.)
I'm just curious what people think would constitue a major version. We've certainly had major rewrites of systems in the past that didn't seem
to
justify a version bump. Is there anything wrong with having version 1.249? Is there a practical reason for bumping the version at some point
(like
when the minor version hits tripple digits)?
Also, a rewrite of MediaWiki should for sure be done in Node.js :)
- Trevor
Is Javascript really that good? Some people dislike prototypical inheritance, it seems that jQuery prefers to use wrappers instead (that's a kind of suboptimal architecture). Also, Google had some complains about Javascript flaws (for example primitive types don't allow high performance available in Java / C#), suggesting to replace it with something else.. Although having common clientside / serverside codebase is nice thing, for sure. And there's nothing more widespread than Javascript at client side. Also, it's object side is strong (something like Lisp with C-syntax), however it does not have generics, named parameters etc.. Dmitriy
A small correction: functional side, not object side. Dmitriy
On Wed, 07 Dec 2011 05:52:31 -0800, Dmitriy Sintsov questpc@rambler.ru wrote:
On 07.12.2011 13:33, Dmitriy Sintsov wrote:
- Trevor Parscaltparscal@wikimedia.org [Tue, 6 Dec 2011 17:21:43
-0800]:
The hype of "2.0" aside, is there a guideline for what should
constitute
a major version number change?
It looks like we are doing something like: Major.Minor.Release
1.18 = Major: 1, Minor: 18, (alpha|beta|etc.)
I'm just curious what people think would constitue a major version. We've certainly had major rewrites of systems in the past that didn't seem
to
justify a version bump. Is there anything wrong with having version 1.249? Is there a practical reason for bumping the version at some point
(like
when the minor version hits tripple digits)?
Also, a rewrite of MediaWiki should for sure be done in Node.js :)
- Trevor
Is Javascript really that good? Some people dislike prototypical inheritance, it seems that jQuery prefers to use wrappers instead (that's a kind of suboptimal architecture). Also, Google had some complains about Javascript flaws (for example primitive types don't allow high performance available in Java / C#), suggesting to replace it with something else.. Although having common clientside / serverside codebase is nice thing, for sure. And there's nothing more widespread than Javascript at client side. Also, it's object side is strong (something like Lisp with C-syntax), however it does not have generics, named parameters etc.. Dmitriy
A small correction: functional side, not object side. Dmitriy
Generics, named parameters? Why are you picking on things that even php doesn't have. If you want names parameters JS is even closer than php. It has a more concise object syntax which means that foo({asdf: 1}) is barely any longer than a normal function call to type, compared to the php equivilant which is foo(array('asdf' => 1)).
And jQuery is jQuery. It uses it's funky syntax for a reason related to what it does.
Now I AM a JavaScript on the server guy (I have a company web application that runs with server side JavaScript and I even participated in the CommonJS pesudo-wg group for awhile) but I'm not so sure about Node.js being the way forward.
Actually, aiming for something with ES5+harmony/next features might even be the best. Traceur could add the features client side.
var {Foo, Bar} = asdf; var [asdf, qwery] = arr; function foo(bar = 5, ...rest) {} for ( let key in obj ) {} (x for ( x of list ) if (x % 2 === 0)) module Foo { export let bar = 42; } var obj = { [variable]: value, foo(bar) { return bar+1; } get baz() { return 5; } }; let text = "qzx$cv"; "asdfzx$cvqwerty".match(re`^adsf${text}qwerty`); "foobar".startsWith("foo"); typeof null === "null";
On Dec 7, 2011, at 10:33 AM, Dmitriy Sintsov wrote:
- Trevor Parscal tparscal@wikimedia.org [Tue, 6 Dec 2011 17:21:43
-0800]:
The hype of "2.0" aside, is there a guideline for what should
constitute
a major version number change?
It looks like we are doing something like: Major.Minor.Release
1.18 = Major: 1, Minor: 18, (alpha|beta|etc.)
I'm just curious what people think would constitue a major version. We've certainly had major rewrites of systems in the past that didn't seem
to
justify a version bump. Is there anything wrong with having version 1.249? Is there a practical reason for bumping the version at some point
(like
when the minor version hits tripple digits)?
Also, a rewrite of MediaWiki should for sure be done in Node.js :)
- Trevor
Is Javascript really that good? Some people dislike prototypical inheritance, it seems that jQuery prefers to use wrappers instead (that's a kind of suboptimal architecture). Also, Google had some complains about Javascript flaws (for example primitive types don't allow high performance available in Java / C#), suggesting to replace it with something else.. Although having common clientside / serverside codebase is nice thing, for sure. And there's nothing more widespread than Javascript at client side. Also, it's object side is strong (something like Lisp with C-syntax), however it does not have generics, named parameters etc.. Dmitriy
I don't know how much you know about JavaScript but in my opinion it's often misunderstood. I think it's superior than most other programming languages because it's very expressive and it's simplicity is what allows great complexity. Bad parts are kept in for compatibility, but once you start treating those bad parts like they don't exist (by not using them, ever) one is left with a language that is still as powerful. (btw, that's the great thing for being a developer, we have the power to basically "remove" parts of the language without changing the standards or breaking other peoples code).
It's fairly easy to use it in a classical inheritance way, (i.e. use "classes" that extend from classes and use "constructors" for creating objects), which can't be said for languages that use classical inheritance, there is no way to do prototypal stuff there.
JavaScript's true power comes into play when using prototypal inheritance directly (creating objects that inherit directly from other objects).
jQuery uses prototypal inheritance as well, it's what makes jQuery what it is.
jQuery('#bodyContent').find( 'a' ).addClass( 'foobar' );
That chain is possible because the jQuery constructor (which is tucked away and calling jQuery( .. ) just does "return new jQuery.fn.init( .. );") which creates an object that inherits all members in jQuery.prototype and does so by reference (not by value)
So when a jQuery plugin is loaded onto the page at any time (that defines jQuery.prototype.myPlugin), all existing jQuery objects will have that method. And because all those methods return "this", you can call another method on the return value in a chain, and so on.
jQuery did choose not to extend the browsers' native objects' prototypes but that's purely a policy created because of how browsers work not because of how the language itself work, it's technically possible and other libraries such as MooTools do do that.
Indeed it's functions are primary citizens and object system is what makes it so strong. Since virtually any value other than null and undefined is an object, including numbers, strings and functions.
Le Fri, 30 Dec 2011 18:31:30 +0100, Krinkle krinklemail@gmail.com a écrit:
Since virtually any value other than null and undefined is an object, including numbers, strings and functions.
Much like ruby! http://ruby-doc.org/core/Integer.html
$ irb
5.upto( 10 ) { |num| print "#{num}ber," }
5ber,6ber,7ber,8ber,9ber,10ber,=> 5
print 4.even?
true=> nil
You can change the 'even?' behavior to do something else of course :D
On Tue, 03 Jan 2012 06:14:36 -0800, Antoine Musso hashar+wmf@free.fr wrote:
Le Fri, 30 Dec 2011 18:31:30 +0100, Krinkle krinklemail@gmail.com a écrit:
Since virtually any value other than null and undefined is an object, including numbers, strings and functions.
Much like ruby! http://ruby-doc.org/core/Integer.html
$ irb
5.upto( 10 ) { |num| print "#{num}ber," }
5ber,6ber,7ber,8ber,9ber,10ber,=> 5
print 4.even?
true=> nil
You can change the 'even?' behavior to do something else of course :D
;) Oh no, in Ruby EVERYTHING is an object, there is no 'virtually' or 'almost'.
nil.class
=> NilClass
puts "nil is nil" if nil.nil?
nil is nil => nil
nil.is_a? NilClass
=> true
Although, their booleans are awkward.
true.class
=> TrueClass
false.class
=> FalseClass
true.class.superclass
=> Object
false.class.superclass
=> Object Last I checked the way to say "Is this a boolean?" in Ruby was `value === true || value === false`. Ugh.
In JavaScript we have Boolean instead.
On 7 December 2011 10:33, Dmitriy Sintsov questpc@rambler.ru wrote: ...
Is Javascript really that good? Some people dislike prototypical inheritance, it seems that jQuery prefers to use wrappers instead (that's a kind of suboptimal architecture). Also, Google had some complains about Javascript flaws (for example primitive types don't allow high performance available in Java / C#), suggesting to replace it with something else.. Although having common clientside / serverside codebase is nice thing, for sure.
Vanilla javascript is not good, and anything complex built on top vanilla javascript will sink if it gets too large, or was built withouth strong guidelines. People has started writting frameworks for javascript, so nobody has to write vanilla javascript. Stuff like http://documentcloud.github.com/backbone/
But I have not seen anything really big written in javascript (except perhaps the ofuscated version of Gmail js).
For his fans, Javascript is Batman, and the Internet is Gothan. In the last 5 years javascript has promised to solve all world problems, forever, and and delivered on it. The thing with Javascript is that it has not changed, what is evolving is how people use it, and is becoming better and better and better at a impresive speed.
The true test for the javascript power will come on the next years, wen people start building complex thing (using framerworks like backbone) and success... or not. I think the future for js is not written jet, and to be honest I am very excited because the latest developments are scary awesome.
On 7 December 2011 01:21, Trevor Parscal tparscal@wikimedia.org wrote:
It looks like we are doing something like: Major.Minor.Release 1.18 = Major: 1, Minor: 18, (alpha|beta|etc.) I'm just curious what people think would constitue a major version. We've certainly had major rewrites of systems in the past that didn't seem to justify a version bump. Is there anything wrong with having version 1.249? Is there a practical reason for bumping the version at some point (like when the minor version hits tripple digits)?
Drop the first digit, as Java and Emacs did.
The current release is MediaWiki 18. MediaWiki 19 is in progress.
- d.
We've tended to replace parts piecemeal; much of the underlying architecture has changed *dramatically* in the last 8-9 years but there's never really been a single cut-off point for "the whole thing" -- even when we swapped out cur/old for page/revision/text, or supplemented/started replacing the entire JavaScript infrastructure, large swaths of the code remained as they were, and there was often a lot of compat assistance.
As for potential future things that might earn a 2.0 label without a "full" rewrite, key things I'd look at that are likely feasible include:
* a MAJOR user-interface redo, moving towards an active front-end that communicates with the backend over API. A heavily HTML5/JavaScriptable frontend that can do offline work, use modern facilities for keeping a single "page" going while making using of history / URL updates to make page switching faster, more touch-orientation (eg like Brandon's "Athena" design mockup) so it scales up and down to large desktop screens, small desktop screens, small smartphone screens, and touch tablets.
Most importantly would be clean separation between frontend and backend: this would potentially affect every skin, every Special: page and a lot of custom code that works in the UI.
* major overhaul of storage/versioning/naming to support different datatypes like video or interactive programs really natively, branched versions, public and private drafts & sharing, etc
It may be that the former is easier to do that it feels, or that the latter might be less invasive than you'd think, but I suspect both will be lots of work at some point. :)
My suspicion is that we'll actually migrate our way slowly into the UI redo piece by piece, and we might end up splitting the other case into smaller pieces as well.
Whether a 2.0 apellation will be deserved at any given time? Honestly it just has to be "major" and user-visible; we don't have to get hung up on which piece at which time. :)
-- brion
On Tue, Dec 6, 2011 at 5:29 PM, Brion Vibber bvibber@wikimedia.org wrote:
- a MAJOR user-interface redo, moving towards an active front-end that
communicates with the backend over API. A heavily HTML5/JavaScriptable frontend that can do offline work, use modern facilities for keeping a single "page" going while making using of history / URL updates to make page switching faster, more touch-orientation (eg like Brandon's "Athena" design mockup) so it scales up and down to large desktop screens, small desktop screens, small smartphone screens, and touch tablets.
IMO a switch to a visual editor as the default editing environment would be sufficient to merit the 2.0 moniker. Heck, it'd be sufficient to get rid of the double square brackets in the logo. ;-)
* Erik Moeller erik@wikimedia.org [Tue, 6 Dec 2011 17:32:06 -0800]:
IMO a switch to a visual editor as the default editing environment would be sufficient to merit the 2.0 moniker. Heck, it'd be sufficient to get rid of the double square brackets in the logo. ;-)
Let's hope that "raw" wikitext still will be available to ones who prefer old fashioned way of article formatting. Dmitriy
----- Original Message -----
From: "Erik Moeller" erik@wikimedia.org
IMO a switch to a visual editor as the default editing environment would be sufficient to merit the 2.0 moniker. Heck, it'd be sufficient to get rid of the double square brackets in the logo. ;-)
And either of those would be a good thing... why?
Cheers, -- jr '{{get-offa-my-lawn}}' a
wikitech-l@lists.wikimedia.org