Mediawiki 2.0

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Mediawiki 2.0

dan nessett-2
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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

K. Peachey-2
http://www.mediawiki.org/wiki/Project:2.0

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Tim Starling-2
In reply to this post by dan nessett-2
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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Chad
On Tue, Dec 6, 2011 at 5:26 PM, Tim Starling <[hidden email]> 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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

dan nessett-2
In reply to this post by K. Peachey-2
On Wed, 07 Dec 2011 07:59:26 +1000, K. Peachey wrote:

> http://www.mediawiki.org/wiki/Project:2.0

Thanks. I have moved my comments to that page's discussion.



--
-- Dan Nessett


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

dan nessett-2
In reply to this post by Tim Starling-2
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.

--
-- Dan Nessett


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Tomasz Finc-2
>
> 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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Neil Kandalgaonkar
In reply to this post by dan nessett-2
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/>.

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  |) <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Daniel Friesen-4
On Tue, 06 Dec 2011 16:18:03 -0800, Neil Kandalgaonkar  
<[hidden email]> 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/>.
>
> 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?

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

dan nessett-2
In reply to this post by Neil Kandalgaonkar
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 <[hidden email]>
To: Wikimedia developers <[hidden email]>
Cc: Dan Nessett <[hidden email]>
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/>.

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  |) <[hidden email]>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Tim Starling-2
In reply to this post by dan nessett-2
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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Ryan Kaldari-2
In reply to this post by dan nessett-2
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
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Trevor Parscal-2
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 <[hidden email]> 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
> [hidden email]
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Brion Vibber-4
In reply to this post by dan nessett-2
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
_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Erik Moeller-4
On Tue, Dec 6, 2011 at 5:29 PM, Brion Vibber <[hidden email]> 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 Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

dan nessett-2
In reply to this post by Tim Starling-2
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.

--
-- Dan Nessett


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Neil Kandalgaonkar
In reply to this post by Daniel Friesen-4
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.

--
Neil Kandalgaonkar  |) <[hidden email]>

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Tim Starling-2
In reply to this post by dan nessett-2
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?
>
> 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.

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


_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Dmitriy Sintsov
In reply to this post by Trevor Parscal-2
* Trevor Parscal <[hidden email]> [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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Reply | Threaded
Open this post in threaded view
|

Re: Mediawiki 2.0

Dmitriy Sintsov
In reply to this post by Erik Moeller-4
* Erik Moeller <[hidden email]> [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

_______________________________________________
Wikitech-l mailing list
[hidden email]
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
12