On Wed, 19 Feb 2003, Caskey Dickson wrote: > > Because of Binc's current behavior, we would always have to allow a select > > on INBOX.a to translate into a select on "a". > > I think this is bad. A select on "INBOX.a" should be a select on "INBOX.a". > A select on "a" should be a select on "a".
I agree. I strongly recommend that you adopt a single sane naming convention. If this breaks backwards compatibility, we should devise a folder migration strategy and program or programs to accomodate upgrades (and/or conversion from Courier). > > At the same time, we could only allow subscription to folders using the > > new format, and only allow creates with the same rule. Thereby moving the > > users to a format where no subfolders are allowed under INBOX unless they > > are there "already". > > Is there a reason to prevent folders under INBOX? The standard doesn't seem > to limit such things. If so, why? If not, then I say leave them. "INBOX" is a special folder name, and translates to a particular folder (presumably ~/Maildir). IMO, all other folder names should be literal. "INBOX.a" should refer to one of "$PREFIX/INBOX.a" or "$PREFIX/INBOX/a" depending on the agreed or configured folder separator. $PREFIX could be ~ or ~/Maildir/ or ~/Mail/, either by agreement or local configuration. > I suppose my question is this: Is bincimap currently translating selects on > "a" to "INBOX.a"? If so, this behavior should be deprecated. Agreed. > If not, then > simply allowing a means to create and maintain root folders--and designating > them, perhaps without a leading '.' would be the best solution. Subfolders of > Maildir/ that are detected as Maildirs are offered up as either subfolders of > INBOX if the beign with '.' or as their own top-level folders if they do not. If you wish subfolders beginning with '.' to present to IMAP clients as "INBOX.xxx", then IMO a migration script should run around and rename "~/Maildir/.xxx" to "~/Maildir/INBOX.xxx". Avoid ambiguity and special cases wherever possible. > > Anyway, it's a good thing to do things like this in early stage of > > development and not postpone it until the server gets really popular. I > > think we can make this work - I'm eager to try. > > I agree, changes like these should be made early on. I'm eager to move > bincimap into my production servers. Me too. > As a side note, I think a solution for root folders that uses a directory > other than Maildir/ is a bad idea. Some of us operate mail systems where the > only user specific directory is their Maildir/, they don't have a 'home' > directory as they are not actual users on the system. (Obviously their > Maildir/ is not named Maildir/) Note your use of "Some of us ...". The key question here is whether the or not the path to INBOX's maildir and the root directory for personal mail folders *must* be the same. I prefer to use ~/Maildir and ~/Mail. I could use just a single directory, say, ~/Maildir, but I don't see the necessity to introduce that restriction. -- Charlie Brady
