Thread:Talk:Extension default namespaces/Social tools' namespaces/reply (9)

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?