On Tue, 6 Jan 2004, Eric A. Hall wrote:
> Right, they are partitions of the underlying mailstore. The partitions may
> be tied to one or more filesystems, or they may be logical representations
> of a filesystem (eg, netnews) or some representation of a database
> subsystem, or whatever.
Or, instead of partitions, they could be separate mailstores supported by
one server, with few or no semantics in common.
> With IMAP, the visible semantic differences tend to be in the separator
> syntaxes, such as a newsgroup partition having a different separator
> syntax than the personal partitions (even if the same filesystem is in use
> for both of them).
There's more to it than that.
UNIX/Windows filesystem namespaces have a \NoSelect root name consisting
only of the hierarchy delimiter. Names are relative to a connected
directory which usually is not the root, but prefixing the name with the
hierarchy delimiter makes the name be an absolute name.
In netnews type semantics such as Cyrus, names are absolute. However,
use of a non-empty LIST reference makes the name in the list pattern
relative to the reference (otherwise clients that use the LIST reference
for a "cwd" are broken). I think that in Cyrus:
LIST foo.bar zap.zowie => foo.zap.zowie
LIST foo.bar. zap.zowie => foo.bar.zap.zowie
LIST foo.bar .zap.zowie => foo.bar.zap.zowie
but I'm not really sure; in practice only the second form is used.
> Obviously I'm not telling anybody anything new here, but its also obvious
> that partitions are discrete units of data (they can even be queried for
> some attributes, but this is very limited functionality), and my feeling
> is that it would be useful to allow their management as such.
I'm still not sure what you mean by "partitions" here. As I understand
it, you're thinking about such namespaces as #shared/ and #public/ in UW
imapd, which are really just aliases for ~imapshared/ and ~imappublic/.
These should be thought more of as "symlinks using the namespace
mechanism" rather than true namespaces, which were designed to allow a
server to export multiple incompatible mail stores.
> > It's difficult to imagine how a protocol can manage creation of
> > namespaces that refer to server based separate hierarchies. Either the
> > server has netnews or it doesn't.
> Well, I don't see a lot of value in that particular example either, but
> that's lots of value in being able to create an #archives partition on the
> fly, assuming that the mailstore allows it.
#news. was the underlying purpose of namespaces. All the other namespaces
in UW imapd were more or less just to fill in that functionality.
We may be talking past each other. If by "partition" you mean "an
application-designated area of the mail store" I think that I grasp what
you're talking about. For such purposes a site can assign a well-known
root-level name (e.g. /shared or /public) and create such names.
I should have done shared and public that way, but I wanted to avoid any
existing use of those names. This isn't a *good* excuse, but it is an
explanation.
As the Japanese say, "even the monkey falls from the tree", and I *was*
born in the Year of the Monkey (so 2004 is my year in the East Asian
calendar).
> The use of special-strings for partition mapping is something separate,
> having more to do with the implementation than with the functionality I'm
> talking about. Servers like UW-IMAP don't have to be excluded here --
> special-strings can be mapped, while undefined partitions can be rooted
> somewhere like /var/spool/imap -- but that's again product specific.
Now I'm completely confused as to your point here. I think that I agree
with what you said here, but I'm not sure... :-)
This is an interesting discussion, though, since the role of namespaces
vis a vis hierarchy is not well-understood. It would probably be useful
if we fleshed this out a bit.
The caution that I should make is that IMAP is quite bloated, and so it
would be better to make any new definitions within the current framework
of IMAP commands and responses rather than attempt to create new ones.
For example, defining CREATE/DELETE/RENAME of namespaces and the semantics
thereof is probably less objectionable than adding new commands. An
existing server would.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
