Enabling ACL for extended names.
Why ACL is so important?
ACL is great thing, specially to wiki administrators. Even if your wiki is a open public wiki, you don't want your help pages to be editable. You want them to be immutable, and when upgrade time comes, you just install a new MoinMoin version and you are done.
ACL is going to be more important in MoinMoin, as it is needed by some new features like AntiSpamGlobalSolution, BlackList and related to NetworkOfMoinMoinWikis. ACL might be on by default on the release, moin 1.3, Q4 2004.
Why do we need ACL for extended names?
One of the best features we have is multi language support. One can register using any name, (possibly own name 
). In 1.3 release, one can use any Unicode character in its name - 1.3 works with Unicode internally, and most things can be Unicode. This is the future - one encoding for all.
There is a severe problem with the current ACL system: It does not support extended names. In 1.2, when ACL is on, you can't register an extended name, or even a name which is not CamelCase. One might get a way with disabling ACL and registering any name, but later, those name are not usable in ACL lines, since #acl extended name:read,write will be ignored by the ACL parser.
This is an abuse of users of Hebrew, Japanese, Chinese, Korean and any other languages which does not have the CamelCase concept. This is not new or unique abuse, you can't use your language for a user name in most operating system. Some let you have a long name, using Unicode, and a short name, using ascii, which is sub optimal. For operating system this may be needed to work with old software that does not support Unicode, but for a web application like MoinMoin, there is no need for such limitation.
This is also an abuse for users of Roman languages, that does not like CamelCase, and prefer the ExtendedLinkPattern. See also LinkPattern
Extended ACL proposal
This is the syntax proposed:
unicode-name = any Unicode sequnce, ignoring leading and trailng whitespace acl_name = CamelCase | unicode-name acl_name_list = [+|-]acl_name[,acl_name]... acl_right = read | write | revert | delete | admin (acl_rights_valid) acl_right_list = acl_right[,acl_right]... Default = (acl_rights_default) acl_rule = acl_name_list:acl_right_list | Default acl_line = acl_rule[ acl_rule]...
One line example:
#acl bad guy,BadGuy: Camel Case Haters,CamelCaseLovers:read,write,revert
For rules containing RTL names, one acl rule per line is preferred, because of general difficulties of editing and displaying bidi.
#acl bad guy,BadGuy: #acl Camel Case Haters,CamelCaseLovers:read,write,revert
It is the same syntax as the current syntax, current ACL lines will continue to work as usual, no convert needed
Here is an example of Hebrew ACL lines:
Implementation
This proposal is implemented in NirSoffer fix branch, patch-18. Anyone interested in this is welcome to play on any page of fix wiki.
Names you put in group pages does not work currently, only names you enter in the page acl line itself. I'm working on a fix. -- NirSoffer 2004-08-31 11:05:47
It works fine, was a configuration problem (Hebrew group regex was not decoded) -- NirSoffer 2004-09-01 00:57:10
Discussion
White space looks fragile. In fact your syntax proposal and your examples do not handle white space precisely. Please define the rules how white space is handled.
White space looks fragile but it does not. white space is used both for separating words in wiki names and for separating acl rules. This means that you can't parse all the rules at once, by acl_line.split() but by parsing one item at a time, as done by ACLStringIterator.
If I was writing this from scratch, I would not use white space for both, but since the current acl system is widely used, I don't want to change this rule. Current acl rules must continue to work, converting old rules is evil and should used only as last resort. We can add an optional separator for acl rules, but I think we don't need this, as this solution works fine, and does not need any new documentation.
Here are more cases when we already use whitespace for both item separator and word separator:
#redirect extented page name [http://example.com/ link label with spaces]
The question i want to ask is: Do we strip user names. Do two blanks count as one?
I did not change the current code - any amount of whitespace is allowed between acl entries. I only added to option to have whitespace within names, which I don't touch. It may be good to normalize whitespace within names, both in ACL lines, user names in groups pages, and new page names. See also the validate section in PageNames.
To make this clear - I don't like the current ACL format, which does not allow proper white space in lists of names and rights. I prefer more natural format like this:
#acl User Name, Another User: read, write, revert
But this means that we can't use whitespace to separate rules, and we will have to change ACL format prepare converter for existing wikis, and deal with all the problems comes with this kind of change. Because of that, I propose the minimal change, that will not effect our current users. In the future we can think of a better more robust and multi language format.
Ok, I think it is not perfect but usable and backward compatible and it is good enough to use it. As long as we don't allow white space in our access rights this should work.