[dovecot] Re: shared folders?

[Timo Sirainen]

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 at 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.