On Sun, Apr 27, 2003 at 05:00:24AM +0300, Timo Sirainen wrote:
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.
Ah okay, that's the part I missed when reading about them. So "inbox", "public" and "shared" are not randomly chosen but actually tell the client (by definition) something about the nature of the folder? Okay, if clients deal properly with that then I'm fine. :)
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.
Yes, and I thought about solving them by having one of them renamed. But it doesn't matter anyways. My only concern was about how current MUAs handle (visualize) namespaces. If they don't tend to introduce any inconveniences for the user then my previous arguments are void. :)
You can of course always just create symlinks manually, but I'd like to support some more user friendly ways.
I like symlinks but I'm not religious about them! ;)
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.
Well, AFAIK most other filesystems do have inode limits. Adding a variable multiplier to the amount of inodes used doesn't seem very elegant to me.
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.
So dovecot better be the only one making changes to the the 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.
I keep reading "NFS safe". To me that's an oxymoron...
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
Well, looking forward to it. I'm a bit worried that dovecot won't be "slim" at all anymore by then, though.
The "simple" shared folders should be fairly easy to implement.
You have read-write already :)
Yes and adding not more but a per-user r/o-option to that would be perfectly sufficient for most of _my_ applications. I ofcourse can't speak for other users...
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.
I'll pretend I've not have read that last sentence...