On Fri, Apr 25, 2003 at 10:52:45PM +0300, Timo Sirainen wrote:
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.
Okay, I get it. (i think)
- 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).
I must admit that I have never really understood (and only very briefly browsed over) the idea of imap namespaces. With the little bit I know I'm basically considering them mainly as a convenience for a person willing to implement an imap server because they make it easier to have the imapd emulate "virtual" folders to the client.
But why not just let the user arrange his folder hierarchy the way he likes when what we are dealing with actually is a folder anyways? I don't see the connection to shared folders. And I don't see a reason why shared folders should be separated in a different namespace?
Your maildir/mbox example makes a bit sense to me even though I don't see the big advantage there either.
But then again, maybe I'm just missing the whole point about namespaces..?
- 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?
Well, I wouldn't do it with the IMAP protocol but with symlinks. ;)
- ..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?
Not at all, I symlink shared folders to the Maildirs of the users that should see them.
- (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.
Yes, that's what I had in mind. :)
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.
Hum.
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.
Hum².
- 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.
The major problem I see is the extensive use of inodes. Also keeping the symlink-copies in sync with the main folder seems like an expensive task to me. And you already have meta files (the index), why not add one?
[ ACL stuff ] [ Moe doesn't like ACL ]
So, you don't want IMAP ACL support at all? I do, but I'll of course leave it optional.
I'd really prefer a simpler approach, at least for a start. The "simple" shared folders should be fairly easy to implement. At least compared to full blown ACL support. Also they wouldn't bloat the code nearly as much as the latter and could easily co-exist with upcoming ACL support while it's under developement.
How good is client support for ACLs nowadays anyways?
- 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.
Yes, you're right ofcourse. But it shouldn't be too hard to issue proper error messages even without ACLs. ;)
- 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.
Well, that's where we have a different view on shared folders. :) "My" shared folders can be read-only or read-write. Trying to delete a message from a read-only shared folder would cause a "Permission denied."-message. I didn't quite understand in first place why that is worth mentioning?
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.
Ah, there we go. :) I don't need users to be able to share/unshare their folders with their mail client and all the other extras ACL makes possible. Thus my call for "simple" shared folders. You on the other hand have the real deal in mind, with ACLs, bells and whistles. Well, whatever it will be, shared folders would definately be a nice thing to have. ;)
greetinx
MW