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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l