Daniel Friesen wrote:
The sentiment that the site-specific reservation added is "silly" seams to be shared by Jack, ^demon, and me at the least. For the record, all three of us are core developers.
Core developers, no less! Well, you have a right to be proud.... MediaWiki is fine software. I guess I'm a core administrator, one of the appreciative folks you've been developing it for.
Gregor Hagedorn wrote:
However, I think the basic request to NOW communicate widely which namespace range should be reserved for site-specific purposes is very reasonable.
Of course their will be not contract, but the present situation is unsatisfactorily. On http://www.mediawiki.org/wiki/Extension_default_namespaces their is no recommendation where to set up your site-specific namespaces. The page says that 100-199 is often used, and extensions should avoid it, but actually some of the most important extensions happily invent their namespaces there.
I don't believe it has to be a 100-block, but a clear commication to all devs: in the future, at all cost, avoid x-y would be welcome.
Maybe it's more difficult for the extension developer (Jack) to move his namespaces, than it would be for us to move ours? In that case, it looks like 900-999 is still free territory: http://www.mediawiki.org/wiki/Extension_default_namespaces
If it were clearly marked as a sanctuary - avoid at all costs, as Gregor says - then we'd never have to spend time on this again.
A further suggestion: either we 1) pick a large block in the high numbers and mark as *definitely* safe for custom, site-specific use; or 2) do the opposite, and mark the whole high area as off limits, "talk to us first". The worst thing is to leave it as it stands now, because it invites future conflicts of the sort that happened in the 100-199 range. It currently says:
For now it would be best to avoid using this range to give sites room to define their custom namespaces without fear of conflict.
And later after those namespaces are defined, the rules may change?
On 11-09-23 08:56 AM, Michael Allan wrote:
Gregor Hagedorn wrote:
However, I think the basic request to NOW communicate widely which namespace range should be reserved for site-specific purposes is very reasonable.
Of course their will be not contract, but the present situation is unsatisfactorily. On http://www.mediawiki.org/wiki/Extension_default_namespaces their is no recommendation where to set up your site-specific namespaces. The page says that 100-199 is often used, and extensions should avoid it, but actually some of the most important extensions happily invent their namespaces there.
I don't believe it has to be a 100-block, but a clear commication to all devs: in the future, at all cost, avoid x-y would be welcome.
Maybe it's more difficult for the extension developer (Jack) to move his namespaces, than it would be for us to move ours? In that case, it looks like 900-999 is still free territory: http://www.mediawiki.org/wiki/Extension_default_namespaces
Changing the default namespace inside of an extension means breaking the extension on nearly every single wiki it is installed in. So yes, it's easier for a site administrator to move namespaces around than it is to change the default for an extension. Also, I'd recommend that any extension that defines custom namespaces to provide a way for site administrators to offset what namespaces are used.
If it were clearly marked as a sanctuary - avoid at all costs, as Gregor says - then we'd never have to spend time on this again.
A further suggestion: either we 1) pick a large block in the high numbers and mark as *definitely* safe for custom, site-specific use; or 2) do the opposite, and mark the whole high area as off limits, "talk to us first". The worst thing is to leave it as it stands now, because it invites future conflicts of the sort that happened in the 100-199 range. It currently says:
For now it would be best to avoid using this range to give sites room to define their custom namespaces without fear of conflict.
And later after those namespaces are defined, the rules may change?
Brion has already marked 100-199 for site administrators.
And I'd like to point out that every one of the extensions currently listed inside that area provides config to use different namespace numbers. So you should have no conflict worries.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Daniel Friesen wrote:
And I'd like to point out that every one of the extensions currently listed inside that area provides config to use different namespace numbers. So you should have no conflict worries.
Maybe we should provide a way to generate namespaces for extensions. The simplest way, using a global which is updated by each extension reserving a namespace is too fragile, but maybe we could produce something similar to ftok(3) to derive a free namespace number.
On 11-09-23 02:52 PM, Platonides wrote:
Daniel Friesen wrote:
And I'd like to point out that every one of the extensions currently listed inside that area provides config to use different namespace numbers. So you should have no conflict worries.
Maybe we should provide a way to generate namespaces for extensions. The simplest way, using a global which is updated by each extension reserving a namespace is too fragile, but maybe we could produce something similar to ftok(3) to derive a free namespace number.
^_^ I said that 3 years ago, and I say it again now.
https://bugzilla.wikimedia.org/show_bug.cgi?id=31063
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
On Fri, Sep 23, 2011 at 11:52 PM, Platonides Platonides@gmail.com wrote:
Maybe we should provide a way to generate namespaces for extensions. The simplest way, using a global which is updated by each extension reserving a namespace is too fragile, but maybe we could produce something similar to ftok(3) to derive a free namespace number.
TimedMediaHandler tried to do this (it picked the lowest free namespace number above 100 or something), and I made Michael take it out. The reason was that variable namespace numbers are very, very, bad:
* It will usually result in the same namespace having different numbers on different wikis * If you add site-specific namespaces or install another extension using the same technique, the namespace number may change and all your pages will be messed up
Roan
Roan Kattouw wrote:
On Fri, Sep 23, 2011 at 11:52 PM, PlatonidesPlatonides@gmail.com wrote:
Maybe we should provide a way to generate namespaces for extensions. The simplest way, using a global which is updated by each extension reserving a namespace is too fragile, but maybe we could produce something similar to ftok(3) to derive a free namespace number.
TimedMediaHandler tried to do this (it picked the lowest free namespace number above 100 or something), and I made Michael take it out. The reason was that variable namespace numbers are very, very, bad:
- It will usually result in the same namespace having different
numbers on different wikis
- If you add site-specific namespaces or install another extension
using the same technique, the namespace number may change and all your pages will be messed up
Roan
Well, that's why I said that a simple approach wouldn't work. Compare the conflict of for ($i = 100; ; $i++) if (!isset($namespaces[$i]) return $i;
with an approach like
$name = 'TimedMediaHandler'; do { $name = md5($name); $n = 100 + hexdec(substr($name, -2)); } while (isset($namespaces[$n])); return $n;
wikitech-l@lists.wikimedia.org