Probably should resurrect the old NamespaceManager idea -- sane thing would be to actually have a table describing the namespaces and such. :)

Looks like an old old version is sitting on bug 7803.

Roan says:

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

Different namespace numbers on different wikis shouldn't matter.

On the second part dynamically registered namespaces should be in a separate area from site-specific ones. Heck with the string idea we might even be able to make new site specific namespaces dynamically registered. Also Brion brought up the idea of a namespace manager, if we do that then we won't have to worry about new site namespaces at all.
As for old ones, we of course are going to need some sort of conversion process to migrate. Something like pre-registering old namespace numbers on upgrade.
And the whole idea of a built-in registry is that installing/uninstalling extensions won't change the fact that a namespace was registered. Heck we can keep the namespace functioning even after the extension was deleted and force people to ACTUALLY delete contents of the namespace before de-registering.

(In reply to comment #3)

Different namespace numbers on different wikis shouldn't matter.

I think it does if you manage multiple wikis. AFAIK in many places in the config the Namespace constants have to be used in ascending order. So config maintainers actually are NOT independent of which number is behind which symbolic constant. That makes configurations non-portable, unless you enforce a global namespace policy on all of your wikis.

Am I correct?

(In reply to comment #4)

(In reply to comment #3)

Different namespace numbers on different wikis shouldn't matter.

I think it does if you manage multiple wikis. AFAIK in many places in the
config the Namespace constants have to be used in ascending order. So config
maintainers actually are NOT independent of which number is behind which
symbolic constant. That makes configurations non-portable, unless you enforce a
global namespace policy on all of your wikis.

Am I correct?

Could you come up with an example of where namespace numbers are required to be in ascending order. I don't see how our config requires that.

Could you come up with an example of where namespace numbers are required to be
in ascending order. I don't see how our config requires that.

for example

http://www.mediawiki.org/wiki/Manual:$wgNamespacesToBeSearchedHelp

(In reply to comment #6)

Could you come up with an example of where namespace numbers are required to be
in ascending order. I don't see how our config requires that.

for example

http://www.mediawiki.org/wiki/Manual:$wgNamespacesToBeSearchedHelp

That sounds messed up I don't see how that config's order should matter to the code that uses it. And if it does matter then that is a bug that should be fixed.

Also with a namespace registry, namespaces would probably start to be managed by a user interface which would likely replace manual use of that config anyways.

I had an extension to this idea in dumps/export/import.

We update the dump format to also include the ="USER" ="SMW_PROPERTY" etc... key that the namespace was registered with.
At that point, during an import we have the information we need to actually pre-register a namespace during an import.

And it'll even work with extensions like SMW since the keys are preserved.
The namespace will be imported, it'll work even if the extension is not installed. And when the extension is installed, it'll just pick up on the contents already in the namespace.

Some of these ideas make me think that custom site namespaces should be registered with some sort of SITE_X key that carries the implication that the namespace was created for a site-specific purpose and the same key from two different wikis may not actually be equivalent in any way.

I agree. Registering and exporting/importing symbolic names like name="SMW_PROPERTY" would make a lot of sense and be more flexible than relying on the key="102" etc. numbers.

The xml format extension would be trivial, but it may a deep change in import/export management. I don't think that SITE_001 is necessary, simply omitting the name attribute would suffice.

For internal management, rather than adding a special table for this, I would prefer to add this to the MediaWiki: namespace.

(In reply to comment #9)

I agree. Registering and exporting/importing symbolic names like
name="SMW_PROPERTY" would make a lot of sense and be more flexible than relying
on the key="102" etc. numbers.

The xml format extension would be trivial, but it may a deep change in
import/export management. I don't think that SITE_001 is necessary, simply
omitting the name attribute would suffice.

We might do that for export. I was considering it.

Internally though I believe we may end up doing things like passing around the "SMW_PROPERTY" string instead of passing around 102 or whatever. Hence we may need something like SITE_X that carries that implication. We may just make one of those implications an implication that the ns does not output an identifier into export.

For internal management, rather than adding a special table for this, I would
prefer to add this to the MediaWiki: namespace.

Hell no.

• We should not need to load the whole i18n system before we load the namespace system. The namespace system should be lighter than that. The i18n system has a whole multi-layer structure (get messages from a cache, potentially share messages across multiple systems, get messages from MediaWiki: [this can be disabled too], get messages from i18n files, get messages from core i18n files). Namespace mapping should not be dependent on this.
  • Actually I believe that the way that Wikimedia shares messages would make this impossible to work on WM as namespace info should be wiki-local.
• Using a database table rather than pages means that we can actually table join it. Instead of the current substandard we have you could actually do a page, namespace join with something like ns_id = page_namespace and title = CONCAT(ns_text, ':', page_title) and get out a REAL title.
• Storing this information in the user editable namespace also has other implications, like making it less efficient and requiring extra db queries to do something simple, and even worse has the potential to let a user completey break their wiki by screwing up something in the MediaWiki: namespace and make it impossible to correct without manual db tweaks. It's also a horrible interface for letting users configure their wiki.
• The fact that a namespace registration system may register the ns number for MediaWiki: and that namespace registration may depend on extracting things from the MediaWiki: namespace means that we have a circular dependency. This is a horrible system design. Heck the i18n system defines aliases for namespaces which means that the namespace system might need to be loaded before the i18n system is loaded anyways.
• MediaWiki: is an absolute horrible place for configuration. This is our i18n system, it's for translations, NOT for configuration. The i18n people hate the fact that this stuff is in there. And others of us want to kill off the i18n hacks we have and turn them into proper site configuration systems.

That was a hornet nest, ok... I am almost convinced by the circular loading argument. Except I have a preference for wikis, that is: put things into a transparent, editable object repository and harvest from there. Like Categories and everything else. There is nothing wrong with having a namespace table, it could easily be harvested off MediaWiki: - except that would mean hardcoding the symbolic name for Mediawiki NS. Advantage: changes are tracked, editability is free (ultimately extensions should probably register their namespace, but for a long time this would require user interaction).

I wish the same were true for the interwiki table: store as a transparent, changeable, version traceable object rather than as database table without version control and user interface. The present interwiki table, would be a bad example of how to manage namespaces. It is not included in import/export. It remains uneditable for how many years? 1000s of people trying to use mediawiki have to figure out which of http://www.mediawiki.org/wiki/Category:Interwiki_extensions they need to install. How many give up? I am adding bug 31951 to call for moving Extension:Interwiki to core, and bug 31955 to address the import/export question for interwiki.

I am not a developer, only a mediawiki farm manager and applied user, so I fully accept your insight into the code structure which I don't have!

(In reply to comment #11)

That was a hornet nest, ok... I am almost convinced by the circular loading
argument. Except I have a preference for wikis, that is: put things into a
transparent, editable object repository and harvest from there. Like Categories
and everything else. There is nothing wrong with having a namespace table, it
could easily be harvested off MediaWiki: - except that would mean hardcoding
the symbolic name for Mediawiki NS. Advantage: changes are tracked, editability
is free (ultimately extensions should probably register their namespace, but
for a long time this would require user interaction).

There's nothing editable at all about formats like MediaWiki:Sidebar. They're horrible hacks with horrible interfaces for what could be a very user friendly special page. And while it's not versioning if we need it we already have a logging system.

I wish the same were true for the interwiki table: store as a transparent,
changeable, version traceable object rather than as database table without
version control and user interface. The present interwiki table, would be a bad
example of how to manage namespaces. It is not included in import/export. It
remains uneditable for how many years? 1000s of people trying to use mediawiki
have to figure out which of
http://www.mediawiki.org/wiki/Category:Interwiki_extensions they need to
install. How many give up? I am adding bug 31951 to call for moving
Extension:Interwiki to core, and bug 31955 to address the import/export
question for interwiki.

I actually have a separate issue with interwiki. IMHO it shouldn't even be necessary to do database changes to change the interwiki table. For a simple wiki with fs access it should be as simple as editing a file. Default interwiki mappings should be done by referring to a core provided file as the default fallback instead of being inserted into the db on install. Wiki farms should be able to have a central interwiki database AND a local interwiki database with overrides, instead of being stuck with either a central one and no overrides or redundant local tables. etc...

I am not a developer, only a mediawiki farm manager and applied user, so I
fully accept your insight into the code structure which I don't have!

1. Having a nice editor for mw:Sidebar would be nice. But nothing in the present format prevents this, it just does not happen due to resource limitation. If it were not in Mediawiki: it would not be editable at all.

2. I don't think logging is a solution, it has not comparison function and is generally rather intransparent. One of the reasons is that user contributions and user logs must be checked separately, rather than being available in a single list. Interestingly, in recent changes they are unified...

3. Wiki admins have neither fileserver nor database access in the installations I know. Since developers have these, they usually believe everyone else has as well. I don't think files are good solution for interwiki.

(4. Yes, the interwiki table is broken, among other things because it manages interlanguage and interwiki in a single table, which prevents sharing the interwiki links by using a shared table. But, perhaps it might be more difficult to update because it is is a non-wiki, classical database design of a dedicated table that is directly edited by third-party tools. If interwiki were harvested and opaque, the update may be more easy. But maybe not...)

(In reply to comment #13)

1. Having a nice editor for mw:Sidebar would be nice. But nothing in the

present format prevents this, it just does not happen due to resource
limitation. If it were not in Mediawiki: it would not be editable at all.

The present format is a mess. And the checks to modify pages necessary for a Special: page to update the sidebar with our full functionality are insane.
A special page updating a sidebar could potentially have to simultaneously edit a half dozen pages. Check that the current user has edit permissions on all of them, if an edit-conflict happens on ANY of them while it's editing it would have to figure out what to do with a half state, and it would have to output multiple entries into the rc instead of a single sane line showing the user has updated the sidebar.

2. I don't think logging is a solution, it has not comparison function and is

generally rather intransparent. One of the reasons is that user contributions
and user logs must be checked separately, rather than being available in a
single list. Interestingly, in recent changes they are unified...

Then file a bug asking for a 'user changes' page that unifies contribs and logs.
And really do you need a comparison function for the change "Dantman added the Foo: namespace", or "Dantman enabled subpages on Help:"?

By the way, namespace updates require checks into what pages are using the namespaces or prefix and a pile of database updates for any relevant pages. By the way, currently if you want to add a namespace you have to do those db updates manually. A Special: page would do these implicitly. But a MediaWiki: page wouldn't, and would expose a site admin to breakage that can only be fixed by someone with database access and in-depth knowledge of how to fix the issue.

3. Wiki admins have neither fileserver nor database access in the installations

I know. Since developers have these, they usually believe everyone else has as
well. I don't think files are good solution for interwiki.

And some wiki are administrated by the user who does have fs access, who shouldn't have to do something as heavy as db or web stuff when file editing is easy for them.
What I'm describing is a configurable multi-layered interwiki system. If file editing is easy for you, then use file editing tools. If you want Special: page editability use a layer with a database and use the Special: page that would come with that multi-layer change. In fact the editability would probably be done by implementing functions on read-write interwiki sources to make changes so any Special: page for editing interwikis could work with any read-write source whether it's database or file based.

(4. Yes, the interwiki table is broken, among other things because it manages
interlanguage and interwiki in a single table, which prevents sharing the
interwiki links by using a shared table. But, perhaps it might be more
difficult to update because it is is a non-wiki, classical database design of a
dedicated table that is directly edited by third-party tools. If interwiki were
harvested and opaque, the update may be more easy. But maybe not...)

A special page updating a sidebar could potentially have to simultaneously edit
a half dozen pages. Check that the current user has edit permissions on all of
them, if an edit-conflict happens on ANY of them while it's editing it would
have to figure out what to do with a half state, and it would have to output
multiple entries into the rc instead of a single sane line showing the user has
updated the sidebar.

I cannot follow, I think the only distributed thing is the localization of
the menu into multiple languages, which, unless everything is changed, would have to remain in Mediawiki NS.

And yes, the Sidebar page could be easier to parse and get a new syntax. But that does not requiring to add a whole new set of tables for it. Create a Mediawiki:Sidebar.json, which, if present, overrides any available Sidebar...

And really do you need a comparison function for the change "Dantman added the
Foo: namespace", or "Dantman enabled subpages on Help:"?

Of course not, I am referring to your proposal that logging does well enough to understand changes in interwiki. But perhaps you can get away with "Dantman changed the interwiki prefix "en" from en.wikipedia to xxx." provided you can filter all "interwiki" logs.

What I'm describing is a configurable multi-layered interwiki system. If file
editing is easy for you, then use file editing tools. If you want Special: page ...

No objections if resources are available for both file and Special: page and all use cases are covered - that would be great!

(Just a thought: If file, please place an additional file in a place specifiable in LocalSettings, rather than requiring to modify code-base provided files (as currently, e.g. "mime.types"). The latter causes issues with wikifarms, svn-checkouts, updating, etc.)

(In reply to comment #15)

A special page updating a sidebar could potentially have to simultaneously edit
a half dozen pages. Check that the current user has edit permissions on all of
them, if an edit-conflict happens on ANY of them while it's editing it would
have to figure out what to do with a half state, and it would have to output
multiple entries into the rc instead of a single sane line showing the user has
updated the sidebar.

I cannot follow, I think the only distributed thing is the localization of
the menu into multiple languages, which, unless everything is changed, would
have to remain in Mediawiki NS.

Yup, they're all in the MediaWiki: NS but when a translations are changed every relevant page has to be changed simultaneously. And the code has to take this into account. Additionally our permissions systems are per-page not per-namespace, and unless the code ensures that permissions are checked for each page individually it's not a proper core feature, it's a hack, and it doesn't follow the expectation that ACL extensions expect when they hook into our hooks for permissions tests.

And yes, the Sidebar page could be easier to parse and get a new syntax. But
that does not requiring to add a whole new set of tables for it. Create a
Mediawiki:Sidebar.json, which, if present, overrides any available Sidebar...

Hell no. Not only is the i18n system not a configuration system, it's also not a place to include a very strict and technical format.
It shouldn't be possible for a user to edit what the special page stores, accidentally screw up the syntax, and then make it so that the special page can't fix what they broke.

By the way, php's json pretty printing isn't implemented till 5.4.0, and that is an alpha. No stable version of php has a native json encoder with the capability to pretty print json.
So because there is no pretty printing, any json outputted by the Special: page into a .json i18n page will be in one long line, not pretty printed with each item on a separate line.
So if you want comparison, a Sidebar.json will look like shit. Our 'diff' will be almost entirely useless for figuring out the difference between two versions of the sidebar.

And really do you need a comparison function for the change "Dantman added the
Foo: namespace", or "Dantman enabled subpages on Help:"?

Of course not, I am referring to your proposal that logging does well enough to
understand changes in interwiki. But perhaps you can get away with "Dantman
changed the interwiki prefix "en" from en.wikipedia to xxx." provided you can
filter all "interwiki" logs.

Special:Log/interwiki

One of the reasons logs are separate from contribs is because they have separate filtering features.
Contribs can filter by namespace, logs can filter by type and title.

What I'm describing is a configurable multi-layered interwiki system. If file
editing is easy for you, then use file editing tools. If you want Special: page ...

No objections if resources are available for both file and Special: page and
all use cases are covered - that would be great!

(Just a thought: If file, please place an additional file in a place
specifiable in LocalSettings, rather than requiring to modify code-base
provided files (as currently, e.g. "mime.types"). The latter causes issues with
wikifarms, svn-checkouts, updating, etc.)

The plan I hoped for was to implement multiple interwiki source types. File (piped list, csv, json, xml, plist, etc...), Database (default database, separate database, separate database and user credentials), etc... and have a $wg variable like our $wgForeignFileRepos that lists multiple interwiki sources letting you use order to specify what sources override other sources.
The default list would contain a file located inside core for our interwiki defaults.
If you don't want those you'd just override the entire way and only specify sources you want yourself.
If you want a file source you would add that to the list yourself including the path to that file yourself, so it's completely customizable. You could even implement wiki farm specifics by having a central interwiki source, a project wide interwiki source, and a wiki specific interwiki source. Any of those could be files or databases.

(this is getting a tad too philosophical and away from the original bug - this was namespaces, not interwiki :-) - but I cannot resist the temptation:)

You describe a "lock it down as safely as you can"-approach of a tightly managed CMS system. And you think of server-side code php.

I was thinking of javascript for the sidebar editor. I think the Mediawiki namespace then is ideal because it allows mediawiki developers to provide initial javascript AND the admins and community experts to override it, just like they can override non-fitting translations.

Sorry for the excursion... And today is bug submission day for me it seems, so I submitted the more general enhancement request bug 31958 on this topic...

Thanks for your patience and your continued good work on mediawiki!

I support the idea of having all namespaces, including pre-defined system namespaces like NS_USER, tracked by a table in the database.

For performance reasons, no functions should be called unconditionally on startup, say from the file level of an extension setup file. It's not clear to me whether Daniel imagines that MWNamespace::reserveExtensionNamespace() would be called from such a context.

Having unique string keys would be useful, but I agree with Happy Melon in CR r103893 that it's best to encapsulate them in an object for most interfaces, rather than passing them raw. Instead of MWNamespace::reserveExtensionNamespace(
'SMW_PROPERTY', 'content' ), we could have something like MWNamespace::getInstance('SMW_PROPERTY')->getId().

I'd rather have some new scheme for namespace string keys, rather than continuing the ugly all-caps style we have now. For example, the user namespace could be called "mw.user", user talk could be "mw.user.talk", and NS_SMW_PROPERTY could be "smw.property".

I fully endorse Tim's notes in comment 18.

I guess I might have thought of extension registration being called in an extension setup function. Though perhaps making use of caching so after the actual registration it's lighter weight.
But I'll consider thinking about some way around that.

For namespaces inside configuration I did think about that.
Even though we'll add a namespace manager I don't think we'll completely eliminate config variables right away. So I did consider an alternative ie:
$wgMyExtsNamespaceSomething = array(

"mw.user" => true,

);

ie: In the mean time switching to string keys instead of integers inside config. As long as extensions are making use of abstract interfaces it should theoretically be possible for extensions to continue working, and core can also try to defer the lookup of the relevant int until needed.

That is where my thought about two methods of code accidentally ending up with a string and an int that are supposed to be considered equivalent.

(In reply to comment #18)

I'd rather have some new scheme for namespace string keys, rather than
continuing the ugly all-caps style we have now. For example, the user namespace
could be called "mw.user", user talk could be "mw.user.talk", and
NS_SMW_PROPERTY could be "smw.property".

Just a wild idea: todays standard system of handles are URI-based globally used identifiers. Ideally, any mediawiki extension should have a page on mediawiki.org in the Extension namespace. Make that the identifier...

(In reply to comment #21)

(In reply to comment #18)

I'd rather have some new scheme for namespace string keys, rather than
continuing the ugly all-caps style we have now. For example, the user namespace
could be called "mw.user", user talk could be "mw.user.talk", and
NS_SMW_PROPERTY could be "smw.property".

Just a wild idea: todays standard system of handles are URI-based globally used
identifiers. Ideally, any mediawiki extension should have a page on
mediawiki.org in the Extension namespace. Make that the identifier...

No, that's not "today's standard system", that's the verbose XML cult of thought.

Extension authors should have no reason to need to type in a full long uri every time they refer to a namespace.

Not to mention how decision on renaming extension pages or switching to a different system for extension management could affect something that should not be dependent on them.

No, that's not "today's standard system", that's the verbose XML cult of
thought.

You mean the Internet and the Semantic Web (including other serializations than xml) is a cult? :-)

Extension authors should have no reason to need to type in a full long uri
every time they refer to a namespace.

Absolutely no need, they would use a local variable name.

Not to mention how decision on renaming extension pages or switching to a
different system for extension management could affect something that should
not be dependent on them.

I don't understand the above.

My assumption is that extensions need globally unique identifiers. Else you either have to create yet another global registry, or two extensions end up using the same identifier. Traditionally many domain specific registries existed, but I stand by my comment: increasingly we do switch these to URIs, whether it is photometadata, institutions, publications, authors, biological organism names, etc. It is not strictly a "standard system" - please excuse my lax use of language. But it is not a cult, it is a well reasoned, sane decision.

(In reply to comment #23)

No, that's not "today's standard system", that's the verbose XML cult of
thought.

You mean the Internet and the Semantic Web (including other serializations than
xml) is a cult? :-)

Extension authors should have no reason to need to type in a full long uri
every time they refer to a namespace.

Absolutely no need, they would use a local variable name.

Extensions shouldn't need to store something like that in a variable. And they WILL need to use it in multiple places in an extension so they WILL have to write it out multiple times.
And the moment they store it into a SMW_PROPERTY like constant all of the extra value of that full uri practically disappears.

Not to mention how decision on renaming extension pages or switching to a
different system for extension management could affect something that should
not be dependent on them.

I don't understand the above.

Say our extension is located at "http://www.mediawiki.org/wiki/Extension:SemanticMediaWiki" and we decide to use the url as the property:
"http://www.mediawiki.org/wiki/Extension:SemanticMediaWiki#Property"

But say we later decide to move "SemanticMediaWiki" to "Semantic MediaWiki". Now the url we're using isn't actually the url that the extension uses. And we can't change that, because that's what we use as a unique identifier and if we change it MW will try to create a new namespace and make all our current content disappear.

Likewise say we ditch the Extension: namespace and switch to some sort of dedicated system that has a special interface for managing extensions, versions, releases, etc... and say we use http://extensions.mediawiki.org/ for that. Now all the urls used in extensions are either incorrect or things break.

Decisions like these shouldn't have an effect on something like the identifier used for an extension namespace.

My assumption is that extensions need globally unique identifiers. Else you
either have to create yet another global registry, or two extensions end up
using the same identifier. Traditionally many domain specific registries
existed, but I stand by my comment: increasingly we do switch these to URIs,
whether it is photometadata, institutions, publications, authors, biological
organism names, etc. It is not strictly a "standard system" - please excuse my
lax use of language. But it is not a cult, it is a well reasoned, sane
decision.

Except we don't need unique identifier at the level of a url.

In fact if we're going by the extension's MW.org page then of the identifier "http://www.mediawiki.org/wiki/Extension:SemanticMediaWiki#Property" the entire "http://www.mediawiki.org/wiki/Extension:" portion of that identifier is worthless.

Quite frankly "smw.*" or maybe "ext.smw.*" is enough specificity for our purposes.
Do remember that these keys we're using all just map to very non-unique things like "Property:", "Thread:", "Video:", etc...
That level of non-uniqueness is not going away, and all we need on top of that for keys is a little differentiation between different extensions, core, and site namespaces.
And for those purposes the extension name is enough (and for well known extensions like Semantic MediaWiki short keys like smw are even enough). We haven't had an issue with conflicts.
And DPL Wikimedia vs. DPL2 isn't a conflict, we'd probably 'want' those to use the same namespace.
And there may be other cases where there's a reason for extensions to share a namespace key.

Having a namespace table –even if just derived from LocalSettings.php– could be handy in ad-hoc SQL queries; it seems a step in the right direction.

Quite right that things like “Property” and “Video” are much too common for extension namespaces! Using URLs to distinguish namespaces is not just XML-like, Java does too, but some abbreviation does seem desirable.