Mark Crispin wrote:
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.
Well, this makes me wonder about the LIST reference even more. The last case
mostly. With UW-IMAP you'd have: LIST foo/bar /% -> /%, so why isn't the last
case above zap.zowie?
Note that I said "I think" that is how Cyrus works, given my understanding
of how I've been told that it works. One of the Cyrus people will have to
say for sure.
(I am one of the growing number of ex-Cyrus people.)
The second case is the important one.
It works correctly for the second case.
I agree that it would probably be more useful if the last case returned
zap.zowie, but I don't think that Cyrus has any concept of "breakout"
characters that take you to the root of the hierarchy the way a filesystem
does (e.g. "/" and "~" on UNIX).
Actually, "a.b" "c.d" => "a.bc.d". I think this is a bug and it should be a.b.c.d. As the instigator of this change, I'm sure I didn't intend a.bc.d, but I was not particularly clever about the implementation here.
Mark's other two are correct.
Just to illustrate Tim's point, here is the output from the most recent version of Cyrus (I CREATEd the bogus compimap.mail group for illustration purposes). The current code just concatenates the reference and pattern and removes any duplicate separator.
. list netnews.comp imap.mail * LIST (\HasNoChildren) "." "netnews.compimap.mail" . OK Completed (0.000 secs 2 calls) . list netnews.comp. mail.imap * LIST (\HasNoChildren) "." "netnews.comp.mail.imap" . OK Completed (0.000 secs 2 calls) . list netnews.comp .mail.imap * LIST (\HasNoChildren) "." "netnews.comp.mail.imap" . OK Completed (0.000 secs 2 calls) . list netnews.comp. .mail.imap * LIST (\HasNoChildren) "." "netnews.comp.mail.imap" . OK Completed (0.000 secs 2 calls)
I never thought about a.b c.d, but if I had, I would have made it do a.b.c.d, not a.c.d. It might be worth fixing. I don't understand why a.c.d would be desirable (doesn't a/b c/d => a/b/c/d on UW?).
I'm willing to fix this, if we can decide which output is correct. Do we insert a separator as Tim suggests, or backtrack to the first separator in the reference as Mark suggests? I think I prefer Tim's idea.
-- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
