On Tue, 6 Jan 2004, Eric A. Hall wrote:
> There are no mechanisms for manipulating hierarchies via the protocol. If
> I want to create or rename a folder hierarchy (eg, create a #public
> hierarchy), then I have to do it off-line since there is no support in the
> protocol directly.
Well, supposedly you can just issue
tag CREATE #public/foo
As far as creating namespaces themselves, these are usually an artifact of
the implementation software and not a level of hierarchy. It may be
helpful to think of namespaces as being like the D: and E: drives in
Windows with the default namespace being the C: drive.
It's perfectly valid for an implementation not to have any namespaces;
think of UNIX which only has one filesystem.
#public/ is an artifact of the UW implementation, and is equivalent to
~imappublic/
Sometimes, namespaces refer to different technologies of mail stores. For
example, the UW implementation has the #news. namespace which refers to an
netnews hierarchy as opposed to a filesystem hierarchy.
> The largest addressable unit of data in the protocol is
> the folder, not the overall mailstore or its individual partitions that
> hold the different folders and hierarchies. Is this a weakness in the
> protocol, and should this support be added?
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.
A possible weakness is that #public/ et al are just things that the UW
server has done as its convention; there isn't any specification that
defines #public/ or #shared/ or whatever.
> Why do so many clients use LIST at the root of the namespace? Can't
> everything they need to discover about that level of the namespace be
> found with the NAMESPACE command, and wouldn't the NAMESPACE command be
> more efficient for what they hope to learn? I must be missing something
> obvious here, since the clear preference is for LIST.
LIST at the root of the namespace is subtly different than the NAMESPACE
command.
The NAMESPACE command lists the namespaces that the server implements,
split into three categories, and their hierarchy delimiters.
The LIST command with an empty pattern lists the root name of the supplied
reference argument. Consider:
tag LIST foo.bar ""
* LIST (\NoSelect) "/" ""
tag OK LIST completed
Now, consider what a Cyrus server might say:
tag LIST foo.bar ""
* LIST (\NoSelect) "." "foo."
tag OK LIST completed
You might be able to infer this from the NAMESPACE command, but it's
harder.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
