Topic on Talk:Extension default namespaces

Apparently my edit was reverted because of some conflicts. Like I wrote in my edit summary, the namespaces conflict with some other extensions' namespaces and site-specific namespaces, but I'd prefer if the other extensions would change their numbers because social tools have been using these namespace numbers since 2007 or so.

Having a site-specific range (500-599) is just silly IMO, sites can and should use whatever NSes aren't registered; who says that custom namespaces indexes can't start from 1000+? I'd like to change TimedMediaHandler's custom NS from 700 to 710 or something; that should be a relatively simple and uncontroversial change, I hope.

This post was posted by Peachey88 (Flood), but signed as Jack Phoenix.

I did the revert. I read your subsequent response on my talk page. Thanks for agreeing to discuss the issue. Please note that the reservation of range 500-599 was open to discussion for 11 months (see preceding section). There were no objections, so we decided to act. The range is now reserved. Manual:Using custom namespaces was altered accordingly. Without a general, prior agreement to withdraw the reservation, I feel it should remain in force. Otherwise, what is the purpose of a registration system?

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

I understand the point about the discussion regarding site-specific namespaces being open for almost a year, but the point is that I didn't read it as I don't actively monitor it, and I'm quite sure that many other developers didn't read the discussion either.

Kghbln suggested that the discussion about site-specific namespaces should be raised on the appropriate mailing lists, which in this case would've been wikitech-l, the development mailing list (yes, mailing lists are so Web 1.0 but they're also how we do things). Many developers, whether they're core, extension or third-party, are subscribed to that mailing list, so by posting there your message will reach the intended audience and you can claim consensus on your changes.

As for the question regarding the purpose of this page, it really depends. To be exact, while many developers might use this page, it still doesn't change what's in SVN — for the time being, BlogPage is using namespaces 500 and 501, no matter what this page says.

Ignoring everything and anything related to site-specific namespaces and namespaces indexes 500-599, what about the other namespaces? While Wikia certainly has a lot of custom extensions and some of them do define their own namespaces, I feel that registration should happen on a per-extension basis instead of reserving a range to Wikia; are their developers even aware of the fact that they had such a reserved range registered on this page?

Extension:NagiosConfig, which has reserved namespaces 600-609, is marked unstable and the latest edit to the extension page has been done on 27 May 2011 and its source code isn't available; Extension:FanBoxes is older, it is marked as stable and it certainly works with MediaWiki 1.16.0, so I feel it should get the namespaces 600 and 601, as it already uses them in the code.

Considering that Extension:TimedMediaHandler hasn't been deployed yet on Wikimedia wikis, I don't think bumping its namespaces from 700 and 701 to something like 710 and 711 or something will be very controversial.

This post was posted by Peachey88 (Flood), but signed as Jack Phoenix.

I wish I could answer your questions, or point to someone who's responsible for the design of the registration process. I think that most of us are simply following the instructions at the top of the page: 'To prevent conflicts in new namespaces added by extensions, please "register" your extension's namespace here.'

If we take care to do that, then things should work out okay.

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

I've changed TimedMediaHandler's namespace ID in r97550. Assuming it doesn't get reverted or FIXME'd within the next 5 days or so, I'll be changing it here and readding my changes back.

This post was posted by Peachey88 (Flood), but signed as Jack Phoenix.

Please do not alter the reserved range 500-599. It was duly registered by prior agreement and the changes you point to would alter it. You cannot act alone in this matter and disrupt the work of others. I recommend you speak to someone in authority. This is a clear conflict, and it arose because you failed to observe the rules in the first place.

This post was posted by Peachey88 (Flood), but signed as Michael Allan.

The "prior agreement" was based on the assumption that no extensions used that range, which as it turns out was incorrect. 500 was already in use by the extension before that "agreement" between three people occurred. I've checked Wikia's repository and it was indeed using namespace 500, before your attempt to "reserve" the range. This is not a "future" extension, it's a preexisting extension that has been cleaned up and added to the official Wikimedia repo.

This post was posted by Peachey88 (Flood), but signed as Reach Out to the Truth.

The de-facto "prior agreement" was 0-99 reserved for MediaWiki internal namespaces (of which 0-15 are currently in use) and site-specific namespaces on 100+ since at least 2004 (MW 1.04 was limited to one-byte namespace numbers). In the half-dozen years which followed, many wikis were deployed with site-specific namespaces just above the internal ones or starting at 100+ like the instructions told the site admins to do.

Unless every wiki which deployed "by the book" using 100+ as site-specific is now expected to renumber all of its custom namespaces to some other range (something which we do not have automated tools to do, short of raw SQL UPDATE commands, as a proper namespace editor never did make it into MW 1.7+ core code) there should be no "reservations" of namespaces in this range to extensions. Quite simply, the designation of 100+ as the site-specific range pre-dates the changes to extensions like DPLforum to hard-code them to namespaces (there was nothing special about 110 or any other namespace number in the original 2005-06 implementation of DPLforum, this is a recent addition breaking existing sites).

If you want to "reserve" some block, use one which hasn't been assigned to site-specific namespaces since at least 2004, please.

If those people want to install an extension that uses namespace numberss that conflict with their wiki's existing namespaces, they can configure or modify the extension locally so it uses different namespace numbers on their wiki. But changing it upstream would adversely affect way more users.

The only namespace numbers that can really be considered "reserved" are those that are already in use on a given wiki.

The issue with DPLforum is that it was *not* hard-coded to any one specific namespace before July 2011; furthermore, once a hard-coded namespace was added, the one chosen was right in the middle of the most-used section for site-specific namespaces (by 2003 convention, 16-99 are for core MediaWiki expansion, 100-254 are free for site-specific use).

Some of us have had DPLforum deployed on high-traffic sites since 2006 (it was developed by user:Algorithm for Uncyclopedia in late 2005) and are now seeing configurations break because this hard-coded 110: is not the Forum: space on the wiki (prior DPLforum versions were manually configurable to any site-specific namespace) and in a few cases is already, predictably, being used for something else because that's where we've been told since 2003 to put site-specific namespaces, 100+

Upgrade DPLforum, watch wiki break in some manner because something was hardcoded after the fact (July 2011) into a space which should never have been used in this manner (the 100+ range allocated in documentation as site-specific, a convention which was in place about eight years prior).

If anything, extensions should not be hard-coding namespace numbers on the blind presumption that they aren't already in local use. At a minimum, there should be some means to override the namespace selection, either to point to a vacant namespace or to match a namespace already configured by the site for use with a prior version of the same extension.

The 2003 allocation of 100+ to be site-specific namespaces predates the after-the-fact 2011 hard-coding of 110: as DPLforum.

Using the extension default namespaces as a space where anyone can edit, claim any existing site-specific namespace as suddenly now belonging to one extension, then complain that it's somehow the fault of the system administrators of existing sites already using that namespace when things break is not the answer. Extension writers have to realise that their code has to be installable on sites where any given namespace, especially the 100+ site-specific area, is likely already in use and stop hard-coding namespace numbers in a non user-configurable manner.

Even the painfully-obvious "well known port" allocations in the TCP/IP world are presumed potentially in use (that's why you can put "Listen 8080" in Apache's httpd.conf if :80's already in use by another web server on your machine...) so why encourage the less flexible approach of hard-coding namespaces with no easy reconfiguration mechanism here?

Oh. Well, no one was discussing DPLforum in this thread until you did. I make no judgments regarding the namespaces declared by that extension, nor do I wish to.