Hello Bron,
> Sorry you missed the rest of the call and we didn't get to talking about your
> thing yet! It was on the agenda for tonight.
Yes, it was a bit spontaneous, I did only realize that the call was
just then, connected, and then my daughter cried and I realized that I
was on duty ;)
> We did talk about it, and figure that the correct thing is to make this more
> generic:
>
> 1) add an annotation called "/hidden" to the mailbox which you can set with a
> name
> 2) if a normal LIST command or even EXTENDED list command is run that doesn't
> support LIST=HIDDEN then don't show those mailboxes (or even show that they
> exist)
> 3) if you say LIST RETURN HIDDEN then they all get shown:
>
> TAG LIST (HIDDEN) "" "%" RETURN (HIDDEN)
> * LIST (\HasChildren \Subscribed) "/" "Foo"
> * LIST (\HasNoChildren \Subscribed \Hidden) "/" "Moo" (HIDDEN ("kolab.com"))
>
> The LIST=HIDDEN aware client can then choose which of these folders to show
> based on the hidden tag.
>
> If there are hidden children then you might get multiple HIDDEN items like
> this:
>
> TAG LIST (HIDDEN) "" "%" RETURN (HIDDEN)
> * LIST (\NonExistent \Hidden \HasChildren) "/" "TopLevel" (HIDDEN
> ("fastmail.com" "kolab.com"))
> TAG OK
>
> TAG LIST (HIDDEN) "" "*" RETURN (HIDDEN)
> * LIST (\Hidden \HasNoChildren) "/" "TopLevel/FastMail" (HIDDEN
> ("fastmail.com"))
> * LIST (\Hidden \HasNoChildren) "/" "TopLevel/Kolab" (HIDDEN ("kolab.com"))
> TAG OK
>
> I think that would match your needs much more powerfully than just a client
> "ID" match, and be flexible for other vendors.
>
> TAG CREATE TopLevel/FastMail
> TAG NO [HIDDEN] A hidden mailbox exists with this name
This sounds like a good way of doing it.
I have reported this to the Kolab list, and we will see if there is
support for changing the clients.
Thank you,
Timotheus
