On 11-09-27 02:18 PM, Olivier Beaton wrote:
Woah woah woah, I definitely didn't (and would
never) say you would'nt
have these things in your wiki, or that mediawiki shouldn't ship with
them.
Currently there are two Recent changes in core, and a few extensions
that have alternatives as well. I don't see why some are extensions
and some are core, why not just have them all as extensions and ship
with one/two of the most popular?
Care to point out an extension that provides a
custom RC page?
The only ones I remember I couldn't track down the source code for or
were complete hacks that rewrote html which naturally would never be
accepted into core or a bundle.
Why are bots using a Special page instead of the api?
Really bots
should use the api, and anything else at least in my mind is a hack
(of which I admit to write my own share). Sounds like the api needs to
be extended if it doesn't fulfil this role. But again I didn't say
don't have this page, just don't have it as core. Still ship with it,
as an extension.
It's not just bots, it's also used for interwiki embedding
of images. I
think I've even used it in the .css of some wiki.
Special:Filepath is a guarantee that if you have File:Foo.png you can
use Special:Filepath/Foo.png and always have it point to the right image.
Simple redirection from a filename to a image path is outside of the
scope of the api.
Same with System Messages and Export/Import.
Especially Export/Import,
I can see people writing great alternatives to those that give me
other options the default ones don't.
Then write them... having something in
core doesn't preclude creating
something better. Moving them out of core doesn't make it any more
likely that someone will write alternatives than providing a way to
override them... which should already be possible.
From the last two messages I really want to stress
that there is a
difference between moving something from core into an extension which
is then bundled into the mediawiki distribution, and not shipping with
a feature at all. I'm all for a feature-rich distribution. I just
think the core should be for absolute necessities only (KISS) and
extensions should provide all the other jazz. That way the core is
small, understandable, documentable and testable. Each extension in
turn doesn't directly interact with a hundred other bits of code, just
their own and the core.
I think everything would be easier with these smaller chunks.
Of course there is a danger of going too far, at what point do you
keep splitting things, and it becomes a big spaghetti mess of modules
everywhere.
There is definitely a line to walk, and while you may not agree with
every item (or many) in my example list, I'm trying to present the
benefits of the philosophy and mantra "not essential? put it in an
extension" and then shipping with it if it's great (maybe even ship
with good alternatives!)
On Tue, Sep 27, 2011 at 4:52 PM, Daniel Friesen
<lists(a)nadir-seen-fire.com> wrote:
> On 11-09-27 06:37 AM, Olivier Beaton wrote:
>> * Recent changes
> This is as ridiculous as removing diffs completely. Revisions, the
> ability to diff between them, and a list of changes are three key core
> features. If you're going to get rid of any of them you might as well
> just stop using MediaWiki.
>
>> * File path
> Special:Filepath is an important special page for linking. If you have
> uploads then Special:Filepath is the only way for bots and other 3rd
> party tools to reliably get a link to a media file. If we get rid of
> Special:Filepath we get rid of the one thing making a rewrite of the
> upload system and paths used a reasonable possibility.
>
>> * System messages
> And what happens when you need to track down a message so you can
> customize your wiki?
>
>> * Export pages (not the api, which can do this)
>> * Import pages (not the api, which can do this)
> No, the API is not an acceptable alternative to the Export/Import system.
>
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
>
>
> _______________________________________________
> Wikitech-l mailing list
> Wikitech-l(a)lists.wikimedia.org
>
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]
