On Thursday, 27 April 2000 at 18:49, Sam Varshavchik wrote:
> On Thu, 27 Apr 2000, Chris Green wrote:
> 
> >     ->  1     IMAP                                ../  
> >     2     IMAP                                Trash 
> >     3     IMAP                                friends
> >     4     IMAP                                isbd   
> >     5     IMAP                                sam 
> >     6     IMAP                                subdir.
> >     7     IMAP                                test   
> > 
> >     But selecting the .. just produces the same display again, it
> >     doesn't take me back up to INBOX.  Entering the full name of the
> >     INBOX or ! works OK.
> > 
> >     Is this a problem with mutt, Courier IMAP, or my configuration?
> 
> Well, there is no such thing as an "../" entry in the IMAP world, that's
> something that's invented solely by mutt.  I'd like to see an IMAP trace
> of what happens when the "../" is selected.  Find an imapd process, then
> strace/truss it, before attempting to return to INBOX.  That should reveal
> what's coming over the wire.

It shouldn't be so complicated. "../" is not transmitted as ../, it is
just a notational convention for "up one level" which many people seem
to find fairly intuitive (not having used Pine's IMAP support, I'm not
sure what other text-based clients use to do this). You can see what
mutt thinks is "up one level" by looking at the status bar for the
current directory. It should be {your.host} if it was previously
{your.host}INBOX . In which case INBOX should be listed via mutt's
NAMESPACE support. Could you send me a debugging transcript of you in
the browser selecting "../" from the INBOX level?

> > 2 - I'm really confused by that subdir. in the above list.  I created
> >     it by hitting 'N' after saving a message.  The folder name I
> >     entered was {x-1.net:50143}INBOX.subdir.david.  When viewed
> >     remotely this appears as expected, a folder david can be found in
> >     subdir.  However on the server system itself there is actually a
> >     maildir directory called ~/Mail/inbox/subdir.david.  I suppose
> 
> Actually, it should be ~/Mail/inbox/.subdir.david, you probably made a
> typo here.
> 
> 
> >     this is just a quirk of the way that Courier IMAP works but it's
> >     confusing to say the least.

<snip IMAP vs filesystem namespace lesson>

> that information.  Labeling the link to the parent hierarchy as "../" will
> only confuse people, when they're talking to a server that does not map
> the IMAP namespace onto the filesystem.

.. is just an abstraction. I didn't want to leave a blank there, nor
did I want to use something like "Up" since that is a perfectly legal
folder name. Since just about anything is, I chose .. because it is
both intuitive and unlikely to be used. Possibly I should have marked
the entry as "up" elsewhere in the folder line and omitted a name in
the name field - this is certainly feasible, I just felt that .. was
intuitive and simple.

> If mutt were to automatically take advantage of self-configuration
> features offered by IMAP4rev1+extensions, it would automatically discover,
> without any additional configuration burden by the user, that:
> 
> A) The folder namespace hierarchy separator is the . character
> 
> B) Private folders are stored underneath the "INBOX." hierarchy
> 
> C) Public folders are stored underneath the "shared." hierarchy
> 
> Mutt obviously figures out the first one, else you won't be able to open
> up folders.  But the other two can also be figured out without any manual
> IMAP client configuration.  All of the above are an implementation issue,
> and there were a number of technical reasons that went into this
> particular design.

mutt does have namespace support, and these should appear, although
frankly these features have only been tested on UW-imap and
Cyrus. Please bear in mind that although it may be annoying to you to
receive bug reports from mutt users when things seem to work fine for
Netscape and Pine clients, from my perspective mutt works fairly well
with uw-imap and Pine but apparently not with courier. mutt's IMAP
support is still young and evolving, and courier likewise is a fairly
new product. I'd rather we work together to solve these interaction
problems rather than have courier assume mutt is broken, and mutt
assume courier must be broken. To that end I intend to install courier
and test, even though I expect that as a relatively immature project I
will waste some amount of energy working around quirks in it which
will later change.

-Brendan

PGP signature

Reply via email to