On Sat, 2003-04-26 at 06:52, Moe Wibble wrote:
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.
Namespaces also tell client if a folder is user's own, other user's or public (eg. news). Client might want to do things differently depending on the type.
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..?
Like Andreas said, the whole point is that you don't get naming collisions between folders.
You can of course always just create symlinks manually, but I'd like to support some more user friendly ways.
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.
Why use maildir at all then? :) XFS at least doesn't have inode limits, I'd guess other file systems nowadays would neither.
Also keeping the symlink-copies in sync with the main folder seems like an expensive task to me.
Hmm. Well, it would require that symlink is updated when flags are updated in original folder.
And you already have meta files (the index), why not add one?
Such flag file would preferrably have to be NFS safe. That makes it a bit more difficult.
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.
Sure. I'm not going to add shared folder or ACL support anytime soon. It's still scheduled post-1.0
The "simple" shared folders should be fairly easy to implement.
You have read-write already :)
How good is client support for ACLs nowadays anyways?
Probably not very good. Bynari's InsightConnector is one which could be useful. Makes it possible to replace MS Excenge with IMAP server for Outlook.
- 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. ;)
Sure. That was just a related TODO item.
- 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?
That meant a folder where each message was owned by a user, and only he could delete the message. ie. unlink() fails for a file in sticky maildir directory because we're not the owner.