[imp] Folders with "." in their Name

[Eric Rostetter]

Quoting Ryan Gallagher <ryan at studiesabroad.com>:

> 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.

Ah, now we're getting somewhere.

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

Okay, this is more interesting than the original claim that it was all
IMAP's with dot delimiters...

> 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).

Okay, makes sense.

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

I think that is configurable via the imp/config/servers.php file.  To wit,
from that file:

 * namespace: This is where you put any paths that you want stripped
 * out for presentation purposes (i.e., you don't want your users to
 * have to know that their personal folders are actually subfolders of
 * their INBOX). A common value for this with Cyrus-style IMAP servers
 * is 'INBOX.'. NOTE: If you have shared folders, using this may
 * create confusion between shared folders and personal folders, if
 * users have folders with the same name as a shared folder.
 *

So you can control the path displayed, to some extent, via this parameter.
Since this appears to be a static string, however, it wouldn't be useful
for hiding user inputed paths...  So I guess it isn't of relavence here.
And without it, yes, it should return the entire path (perhaps excluding the
"folders" prefix also set in servers.php).

> I'm not sure if Cyrus should be configured to use a less common delim

It seems that no matter what you choose, someone will try to use it at
some point, so this would not solve the problem (but might lessen its
occurance).

> or if IMP should be altered to support Cyrus's extra features.

Interesting question...

> 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

And even more so to those of us who run other mailers, and until now had
no idea what you were talking about... :)
 
> 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.

Cool. (I guess)

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

Yes, and that no doubt accounts for the confusion and lack of responses on
the list also.
 
> So the 10million dollar question of "Is it a feature or bug?".   Kinda both,

Or a cyrus feature interfering with an IMP feature, and hence causing a 
Cyrus specific bug?

> Sorry for the length.

Don't be.  At least now we understand the problem!

> --Ryan

-- 
Eric Rostetter
The Department of Physics
The University of Texas at Austin

Why get even? Get odd!