On Tue, 6 Jan 2004, Eric A. Hall wrote: > Okay, semantics first. Servers have one (logical) mailstore. The mailstore > may contain one or more subordinate stores, which are essentially > partitions. Whereas you are saying that a server may have multiple stores, > I'm saying that those are partitions of a single (logical) mailstore. Just > as something like 'the' UNIX filesystem may consist of multiple > partitions, each of which are actually different filesystems but which are > logically represented consisted.
That's a good definition, but that isn't what IMAP namespaces sought to accomplish. For your purposes (given the examples of archive and policy), I think that simply creating a new name at the root of the default namespace is better and much less trouble. I understand the attraction in being able to use the NAMESPACE mechanism for your purpose, but as you noted it doesn't work well to do that now and it's probably not feasible to hope that we'll see widespread adoption of extensions to make it do this. IMAP namespaces were meant to act as a bit of glue to tie together multiple independent hierarchies which otherwise could not be reconciled in a single namespace due to fundamentally different semantics -- e.g. filesystem vs. netnews vs. database. The NAMESPACE command serves two orthogonal purposes: it lists the server-supported namespaces and it gives client hints on how to access "my mailboxes" vs "other users' mailboxes" vs "global mailboxes". There are many good ideas that fail, not because they were bad ideas or "not good" ideas, but just that they weren't overwhelmingly good enough. The barrier that your idea needs to overcome is "why not use a root-level name instead of a namespace." -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
