[dovecot] Re: shared folders?

[Moe Wibble]

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