On Fri, 2003-04-25 at 21:48, Moe Wibble wrote:
- Change maildir hierarchy separator from '.' to '/', so that usernames could be used in mailboxes names without ugly mangling. Huh?
So that if you have a login name of "first.last@domain.com", LIST could show that directly under "Other users/" namespace.
- Namespace configuration:
- namespace_[private|user|shared]_prefix
- MAIL environment (or default_mail_env) additions:
- USER_SHARED=.__my_shared_store__
- SHARED=/somewhere for globally shared
- NAMESPACE command
What for?
I'll do this in any case. Namespaces are good for clients and people want multiple locations for their mailboxes (mixed mboxes and maildir most commonly).
- Support for multiple namespaces
- struct mail_storage == one namespace
- fix all IMAP commands handling mailbox names to support other mail_storages based on the mailbox name prefix
Ugh.
Same as above.
- mail_storage implementation for shared maildir folders
- SUBSCRIBE shared/timo.sirainen/folder would create .shared/timo.sirainen/folder/ and build indexes there
- UNSUBSCRIBE would delete it
Why!?
Point was to be able to share your folders with other users. How else would you do that with IMAP protocol?
- ..or should SELECT shared/user/folder work before being subscribed? (Later at least yes, but that would need special handling)
- LSUB could simply return all the folders in .shared/ dir
- LIST could use user-defined plugins
Why why why!?
How would you list the possible folders that other people have shared?
- (Courier compatibility? It used some extra files)
Why not treat shared folders like any other folders?
Because they're not like other folders. Unless you want to manually create the symlink and delete it when you don't want that folder anymore.
Why the heck do you want to be "compatible" to inconveniences of other software?
That was in paranthesis :) And it's not a big deal, maybe creating a 0-byte file.
Wouldn't a one-shot-convert-courier-mailstore-to-dovecot-mailstore- utility be more reasonable than bloating the code with compatiblity- workarounds? Who in the world would want to run dovecot and courier in parallel?
There may be other programs that access Maildir++ than Courier. Maybe not shared folders, but for quota there's several others.
- Separate per-mail symlinks to allow per-user mail flags
- mostly just about syncing symlink directory with real directory
Ummm. per-mail symlinks? Okay, there are a number of reasons why people want to get rid of courier imap. I'm convinced that would be one of them! Why not store per-user mailflags for a shared folder (shared folder = a folder that is a symlink not directory) in a separate (single?) meta-file? So dovecot sees: "oh a symlink. well, we'd better read the flags from our meta file then, rather than parse the name".
I think the symlinking is quite simple way to do this and plays very nicely with how maildir works internally. If I do some separate meta-file for flags (I've thought about that too) it wouldn't be maildir anymore. I might just as well implement another mail storage format then.
- ACL API design
- Needs to support stackable implementations, so that eg. filesystem ACL is at the bottom, on top of that an .aclrights file for more fine grained non-OS forced ACLs.
- compatible with ACL2 (currently draft), just a few issues
Okay, you're kidding. You are. Aren't you? You are. (*hides under desk*)
- Filesystem ACL implementation for the ACL API
Argh.
- ACL IMAP commands
Mercy!!
So, you don't want IMAP ACL support at all? I do, but I'll of course leave it optional.
- Make existing commands play nicely with ACLs and shared folders
- Say "permission denied" rather than "internal error" if some syscall returns EACCES (mostly when opening folders)
Hm. Ah, that's what we get out of all the effort?
It's not nice to let users fill your error log files.
- When trying to expunge a message that wasn't ours, ignore or give human readable error message (which one?), but don't give "internal error"
Umm. Does anyone really care about that?
Depends on how you want the shared folder to behave. Yes, the guy who I wrote this mail first wanted such behaviour.
Would you probably take a simpler approach like the one I briefly outlined in my previous mail into consideration or do you really think of ACLs as a must-have? If so, why?
If you can't give shell access to IMAP users, that's the only way to let them share their folders.