On Wed, Feb 19, 2003 at 11:39:05PM -0500, Charlie Brady wrote:
> > Binc to be a drop-in replacement.
>
> If we were happy with Courier we wouldn't be here, right?
Absolutely, and if we want to convert Courier users to Binc we can't require that
every existing mailbox be converted as well.
> I started this thread, so please allow me to reiterate my original
> question - why can't I create a folder called "foo"?
Because currently Binc has the same limitation as Courier, namely all folders must be
a sub-folder of INBOX.
> Leaving aside for the moment the on-disk storage structure, does Courier
> have this restriction - that one can only create folders called
> "INBOX.xxx"? [Excuse my ignorance - I've thus far found Courier-IMAP be
> too big a pill to swallow in a single sitting, and have struggled with
> patching maildir patches of WU-imapd for my sins.]
Unfortunately, as the best-of-the-worst at the time, I've had to swallow the Courier
pill several times and I am eager to be rid of it. Courier has this silly limitation,
as well as using 'dot' as a path separator in local storage. Therefore (I presume)
Binc has it as well.
> > 3) Do both via some kind of configuration mechanism
> As I see it, this can all be done with three configuration items - path
> separator, path to INBOX maildir, root dir of non-INBOX folder tree.
I agree that making it configurable would be great, my only concern is that root-level
folders are allowed by the spec, and therefore Binc not allowing them is an artificial
limitation that is specific to Binc.
> My preference is for these to be '/', ~/Maildir/, ~/Mail/, but I'm happy
> for you to have whatever you want.
The only problem with this, is what would happen when you set the second and third to
the same thing, as would be needed for an IMAP-toaster.
> Why isn't it "foo.bar"? And how is the client to know that folders must
> begin with "INBOX."?
I'm no expert, but I believe it is just something that fails if you
don't create it as a subfolder. CREATE "INBOX.foo.bar" succeeds while
CREATE "foo.bar" will fail.
> > >>I would rather time be spent on furthering Binc's IMAP conformance than
> > >>accomodating other software's interpretation of reality.
>
> As long as it conforms with Courier's interpretation of reality, eh? :-)
Something like that.
> > And what I'm arguing for here is that the notion of changing something that
> > already works to make it work differently (but as you insist, better), is
> > secondary to making Binc comply with the IMAP protocol which allows for root
> > folders.
>
> RFC 2060 doesn't help us here - "The interpretation of mailbox names is
> implementation-dependent". This includes, as far as I can tell, any
> decision on what is and is not a legal mailbox name.
Yes, and Courier decided that all folders are subfolders of INBOX, which we all agree
is silly. By 'allows for root folders', I mean't to say 'doesn't prohibit' and I
think we'll all agree, that unless the spec prohibits something reasonable, Binc
should be able to support it.
> > Changing something that works is not as important as adding something that is
> > missing.
>
> But does BINC work? I want a folder called "foo", and I can't have one.
> Yet! But I'm confident that is about to change :-)
Correct. However, creation of subfolders of INBOX does work, so we should focus on
adding/fixing creation of 'foo'.
> > Better the hard truth than the comforting fantasy. -- Carl Sagan
>
> [Hmm, so why chase the needle in a trillion haystacks of SETI, Carl?]
Good question. I'll ask him the next time I see him. :-)
C=)
--
--------------------------------------------------------------------------
Better the hard truth than the comforting fantasy. -- Carl Sagan
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
A presumption on your part does not constitute an obligation on my part.
