[imp] Folders with "." in their Name

[Ryan Gallagher]

Quoting Eric Rostetter <eric.rostetter at physics.utexas.edu>:

> Quoting Ryan Gallagher <ryan at studiesabroad.com>:
> 
> > Quoting Jan Schneider <jan at horde.org>:
> > 
> > > Zitat von Joerg Battermann <jb at startupx.com>:
> > >
> > > > when creating new folders, it seems like IMP doesn't check for "."'s
> in
> > > > the name.
> 
> In what sense doesn't it check?  Do you mean you think it should recode
> these
> to some other character?  Or do you mean it isn't recognizing them as a
> mailbox hierarchy seperator and treating it as such?  Which do you consider
> the correct action?
> 
> > > > I just created a Folder e.g. "ABC.DEF", and now it seems like IMp
> > > > can't handle it properly.
> 
> In what sense?  I would expect that, unless I've set my Mailbox Hierachy
> Seperator differently, that it would create a folder ABC, and inside that
> create a subfolder DEF.  Is this what it is doing?  Is this not what you
> expect for some reason?

Cyrus creates a _container_ object "ABC", and a _mailbox_ object "DEF".  The
container object appears to be the root of the problem.  See my additional
comments at bottom.

> > > > I can't delete the folder anymore, because IMP
> > > > displays DEF as a subfolder of ABC, where the actual Dir -is- ABC.DEF
> :\
> 
> I would expect it to do as you say IMP does -- A folder ABC with a subfolder
> DEF.  Does it work that way?  Or it it a bug in that it creates an actual
> folder ABC.DEF, but then accesses it as two seperate folders when it is
> really one?
> 
> Please try to clarify what exactly you expect it to do, what it is doing,
> and why you think that is wrong.  I can't tell from your posting details
> if this is a bug or a feature.
> 
> > > That's a "feature", not a bug. ;-)
> > > Jan.
> 
> Probably, but it is really hard to tell from just the details he gives.
> 
> We need more details to actually understand if it is working or not.
> 
> > alter the full path) but the resultant behavior is entirely too vague and,
> > IMHO is not appropriate for the user audience HORDE claims to target.
> 
> Okay, how is it too vague?  And what audience is Horde claiming to target?
> 
> Is your problem that we let you type in folder hierachies, rather than
> making
> you enter them one by one in sequence?  I'm not sure at all what your
> complaint
> is.
> 
> > It's a 'bug' with any IMAP backend that uses the default delimiter of "."
> for
> > mailbox names (Cyrus here).
> 
> If so, I assume it is the same bug elsewhere, just by changing the character
> to match the backend's hierachy character, no?
> 
> >  Using an alternate delimiter in IMAP should not be
> > necessary for getting IMP to behave.
> 
> Again, behave how?
> 
> I'd really like to help, but I just have no clear idea of what it is you
> consider a bug, why you consider it a bug, and what alternate handling of
> it you desire.
> 
> -- 
> Eric Rostetter

HORDE 2.1
IMP 3.1
Cyrus IMAP (with default mailbox delimiter configuration)

Okay... some more details.  And it's appearing to be a cyrus specific behavior
outside of RFC IMAP spec.

Basically IMP is telling Cyrus to create "foo.bar" mailbox (with "foo" not yet
existing).  Cyrus, because it supports a non spec _feature_ called CONTAINERS
(which are essentially objects, much like mailboxes, that contain other objects,
but cannot store messages) translates this IMP in-spec command into: I should
create "bar" mailbox with containers as necessary to satisfy the requested path
to "bar".  This is because the default cyrus mailbox delimiter is "."

So you get:
[foo] <--- container
 + (bar) <--- mailbox

And as the other user pointed out [foo] the container doesn't play very friendly
with IMP, nor does it break it entirely, it merely displays as a mailbox (folder
icon instead) and cannot be manipulated as other mailboxes can (delete,
subscribe, store messages there-in).

So when renaming an existing mailbox you are given the whole "." delimited path
to edit.  If any of your edits alter the path to the final leaf object, then
cyrus dynamically creates containers as necessary to satisfy this rename request.

Does IMP give you the full path under other IMAP backends?  

I'm not sure if Cyrus should be configured to use a less common delim, or if IMP
should be altered to support Cyrus's extra features.   But the point being, the
resultant behavior can be very confusing to users who barely grasp the concept
of "subscriptions" let alone these "containers" that they can't remove and maybe
created on accident when using .'s

For reference, once you have a container, the only way to deal with it is to
create a true mailbox named the same, with the same path, instead of saying "it
already exists", Cyrus says "Ohh, I should upgrade it to a full mailbox", and
does so.  IMP lets you perform this task without error.

Changing the cyrus delim would only solve part of the problem with IMP, because
then re-name dialogs could get really ugly.  The user might be presented with
the following.

MyLists%Horde%Imp

My instinct is that when renaming a mailbox object, the path up to the leaf
object should be ignored and not displayed (but this might simply be a cyrus
behavior).  By doing so it would remove your ability to "move" mailbox objects.
 The subsequent request would be to add the "move" feature separately in a more
intuitive context.

Are you seeing the potential confusion this could cause users?  And again, it
appears to be a Cyrus only behavior.

So the 10million dollar question of "Is it a feature or bug?".   Kinda both, and
the blame is hard to place.  IMP+Cyrus combinations could be vastly improved if
IMP knew about cyrus's quirks/features.  For power-users i'd vote feature, for
novice users i'd say "unexpected and confusing behavior".  But as I mentioned, I
believe that IMP isn't trying to leave the novices in the dark.

Sorry for the length.
--Ryan