store a list of names into meta[NAME]
currently, meta[NAME] has a single unicode value (the item name).
it could be changed to be a list of unicode item names.
all these names would be valid names for the item, maybe with some preference on the first one (e.g. if we need to display the name).
like for tags, searching for name_exact:foo would automatically search the list for a member "foo".
practically, this would make the following stuff possible: having "alias names" for items make same thing show up at multiple places (like hardlinks in file system) not needing redirect items if you "rename" an item (== add another name to the list) that is linked from other items or from the outside the name list could have zero elements, making the item somehow vanish from the surface (namespace, index) and be "deleted" (but still being there in storage, just not having a name, but still an itemid, revisions, etc.). the name(s) it had before can still be fetched from its parent revision.
related idea because of that name-based routing issue if you don't have a name:
maybe we have the wrong concept here (mounting backends into the namespace as posix OSes are doing it), like
if we would have different namespaces rather, which are a prefix and not part of the visible "item name", we always would know where to put stuff, like:
Note: interwiki markup is OtherWiki:OtherItem
problem: ambiguity between 2 and 3.
to solve, maybe we could maybe automatically detect whether it is a namespace (we know the local ns names)
also, swedish and finnish use colons in normal words, event introducing more ambiguity, see
Solution idea:
Names in markup would look like this (wn is wikiname, ns is namespace, pn is pagename):
wikiconfig:
Note: we store the namespace info into revision metadata, so we can store multiple namespace's revisions into same backend.
creating interwiki URLs with namespaces: maybe we can extend interwiki map a bit:
Note: using this interwikimap (and our own namespace map), we can know what namespaces the remote wiki has, so by doing some lookups into the map, we can decide what's the interwiki:ns1:ns11 part and what is maybe a strange foo:bar finnish word.
if we do that, we need to rethink serialization also. it should serialize 1 backend per call.
we need to be careful about this:
You see it is somehow similar and the url spec is so wide it is not helping us. We currently have a list of known protocols to solve this, but we should advise users not to create namespaces or interwikinames that can be read as a protocol (at least not one they want to support in the wiki).
Note: additionally to having a userprofile namespace, we could have a user namespace for homepages.
also, we need to tell users not to create pages with names that start with <somenamespacename>:
and use validation to make sure.
we already have a similar problem with interwiki, so this is not new.
Ok, this issue is getting rather big, so we split it into multiple issues that should be done in this order (roughly, some stuff might be doable in parallel):
this issue is being worked on in namespace branch.
2,3,4 is done
7 is done
8 works for >= 1 names at least, needs checking for 0
I think the concept of hierarchical acls like we had in 1.x won't work with this implemenation. See also for a new idea.
the issues pointed out in comment 16 can maybe be solved in 2 ways: using only the first name for hier. acl computation. using only the currently used name (see url) for hier. acl computation
hierarchical ACLs are solved by