On Thursday, Jul 10, 2003, at 15:06 Europe/Helsinki, Stuart Henderson wrote:
Perhaps there could be one level of 'folder' containers allowed inside 'namespace' in the config...
namespace { prefix = type = private separator = . location = maildir:~/ folder { name = INBOX location = mbox:/var/mail/%u separator = / } }
Yes, it has to be done something like this. namespace { .. } would map into one real namespace reported by NAMESPACE command.
I think it may be something of a problem to expose different separators for different parts of the hierarchy... any clients which don't understand 'namespace' won't have a clue, and I suspect that some clients which do understand 'namespace' might not cope with different folder separators in different namespaces.
Possibly. It may be required however if some namespace contains mailboxes containing the default separator, and vice versa. And separators can't be escaped.
Anyway, I think I won't allow using multiple different separators inside one namespace. That may be allowed by IMAP RFC, maybe even the NAMESPACE RFC but it's clearly against how it was thought to be used.
So I think that 'separator' in namespace/folder config should refer to 'internal' namespace, and translate for the user.
There's no point in specifying internal separator in most cases. Only possibly useful case would be if you wanted Maildir++ directories to use something else than '.', but that wouldn't be Maildir++ anymore and if you really wanted that, you could just recompile with some #define changed..
What does INBOX.foo do? What about INBOX/foo? Maybe there should be allow_subs = (yes|no) for folders (to set whether subfolders should be created with that 'style' or whether they should be created in the parent namespace).
I think it's better to always create them under the child mailbox. It's cleaner that way and less confusing. So if you had mbox INBOX while rest was Maildir, you'd have the INBOX marked \NoInferiors tag. Although I'm not sure if it should be done when there's another namespace that begins with INBOX.. Probably shouldn't, especially because not all clients understand namespaces. That makes it a bit more complicated..
If namespace configuration is being looked at now, it would probably make sense to ensure that it will be flexible enough to cope with as many future requirements as possible without change. I'm thinking of post-1.0 possiblities here, i.e. ACLs...I think that it might be worth examining any possible namespace config to see whether it's capable of implementing ACLs without big changes to the design.
Yes.. But I can't really think of what problems the above configuration would have after adding ACLs. You could just add some acl = <value> entry there.
Besides 'system' shared folders with ACLs, Cyrus has 'user' shared folders which it places in an 'other users' namespace (normally user.*) - this is *really* useful...
Yes, this is a separate namespace type as well. I just didn't mention it yet since it's a whole different problem which is most likely post-1.0 feature.