https://bugzilla.wikimedia.org/show_bug.cgi?id=31063
Web browser: ---
Bug #: 31063
Summary: MediaWiki should use a reservation system for
namespaces
Product: MediaWiki
Version: 1.19-svn
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General/Unknown
AssignedTo: [email protected]
ReportedBy: [email protected]
Classification: Unclassified
Right now to handle namespace numbers extensions have to hardcode default
namespace numbers into their code and define constants with them for use in
code. This results in the need to list them in a central place and keep it in
mind when writing new code to avoid conflicts. Naturally with the uncollected
nature of extension development conflicts arise and there's of course also no
safe place for site custom namespaces.
Rather than forcing namespace implementation details into all these extensions
we should consider instead using some sort of namespace registry in MediaWiki
where namespaces try to reserve a namespace for a key such as "SMW_PROPERTY"
for SMW's Property: namespace which is currently defined by the NS_SMW_PROPERTY
constant.
Such a registry may use calls like `MWNamespace::reserveExtensionNamespace(
'SMW_PROPERTY', 'content' )` and `MWNamespace::reserveExtensionNamespace(
'SMW_PROPERTY_TALK', 'talk' )` to reserve it's namespaces. Or perhaps for
better state a combined `MWNamespace::reserveExtensionNamespace( 'SMW_PROPERTY'
'SMW_PROPERTY_TALK' )`.
When first used MediaWiki will find unused namespace number(s) for the
extensions' namespaces and return them. It will save these reservations in a
registry for namespaces noting that the namespace numbers have been reserved
for the 'SMW_PROPERTY' and 'SMW_PROPERTY_TALK' keys. After that the method will
always return the same namespace numbers for those keys when re-called. The
registry will persist the registrations even when an extension is installed and
won't re-use previously reserved namespace numbers unless those are explicitly
deleted from the registry by someone who has cleared all the content dependant
on them from the database. Naturally when an extension is re-enabled because it
uses the same keys it will resume using the namespaces it reserved before.
Nikerabbit notes that in HipHop we can't set constants dynamically. Also it's
fairly awkward that we'll likely have to set them post-config so they'll be
hard to use in other configs.
If possible we should consider attempting to replace numbers and constants in
as many interfaces as possible with keys. Replacing the use of NS_SMW_PROPERTY
with "SMW_PROPERTY" everywhere and turning namespace numbers into an
implementation-detail which is handled exclusively by core while the rest of
the code deals in reservation keys.
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
