Thanks for all the clarifications.

To finish up on a point that you didn't fully understand
and to make a recommendation for your evaluation,

> > - being more comfortable with the concept of being able to make
> >     subfolders of all mailboxes than I am with any folder except INBOX,
>
> Not sure I understand this.

Right now we can create subfolders of INBOX but not folders at
the same level as INBOX.  With the ANN we can create folders at
the same level of INBOX but not subfolders of INBOX.

I am more comfortable with an implementation that allows
for the creation of folders and sub folders wherever the
admin or user determines is appropriate without regard to
whether the folder is named "inbox" or "foo".

> > - preferring that the on-disk structure match the mailstore presentation
> >     (and being that I prefer the alternate namespace I can't have this),
>
> This is obviously next to impossible when supporting two interchangeable
> namespaces.

True, but I don't think it would be very difficult to support
both at the same time if we were willing to make a minor on-disk
modification to add a folder called "inbox" underneath the folder
"username".  It seems to me that if we made INBOX an actual
folder on-disk (lower cased of course) rather than a synonym
for "username" all the problems with separate namespaces would
go away.  All folders created at the top level would appear at
the top level including INBOX, and any subfolders of INBOX
could be created there.

We do have a problem to address with existing implementations.
I could see this addressed in one of two ways:
1) Write a simple script that creates a directory called
    "inbox" underneath "username" and moves all entities
    from within "username" into "inbox"

2) Use an imapd.conf flag which controls using either the
    current code of "inbox.foldername"="username/foldername",
    or the new code which says
    "inbox.foldername"="username/inbox/foldername".

This would of course be down the road because I have no
desire to mess with existing installations at this time.
However, it does seem to me that if we added a folder
named INBOX at the appropriate place and renamed the
separator "/" than we would have simplified the whole
operation of the system and supported both namesapce
options all at the same time which seems like a very
inexpensive modification to make to me.

-- Michael --

Reply via email to