[Dovecot] Is this really a user agent issue?

Phil Howard ttiphil at gmail.com
Mon Dec 27 20:38:36 EET 2010


On Thu, Dec 23, 2010 at 17:08, Willie Gillespie
<wgillespie+dovecot at es2eng.com> wrote:
> Phil Howard wrote:
>>
>> I think this issue has been entirely misunderstood.  Have I explained it
>> wrong?
>
> I think there's been a bit of confusion here.  Everyone is saying similar
> things in slightly different ways.
>
> The IMAP protocol has no way to "push" to the MUA that a folder (mailbox)
> has been freshly created.  This information must be "pulled" by the client,
> ie: LISTing all folders.

Given that it appeared to be a request/response class protocol, I was
expecting that it had no such push ability.


> So, say we have an MUA connected and -something- (whether it be deliver or
> another MUA connected elsewhere) creates a new folder.  With IMAP the
> original MUA has no way of knowing that this just happened.  When it tries
> to create the same folder, the CREATE fails, because the folder already
> exists.

Right.


> How the MUA handles this situation is up to the MUA.
>
> I see a few possibilities:
> 1) it could ignore the situation and just show an error message to the user*
> 2) it could do a LIST and get an updated list of folders**
> 3) it could add the folder to its display***
>
> * Sounds like what your MUA is doing.

Yes.

> ** This could be fine and dandy, but many MUAs use the subscription list
> (LSUB) instead of showing all the folders (LIST).  So just because the MUA
> now knows the folder exists doesn't mean it will show it to you unless you
> SUBSCRIBE to it.

However, if I am not doing subscriptions, shouldn't it show me ALL
folders (per what Charles Marcus said in his message just before
yours)?  Why would this folder be handled differently if it is showing
me all the other folders?


> *** Whether this means that the MUA auto-SUBSCRIBEs you to the mailbox or
> not depends on what mode the MUA is running in.  It seems like this is what
> you want your MUA to do instead of #1.

No, that is not what I want it to do.  What I want it to do is #2 ...
and show me ALL the folders, with the new one included from the most
recent LIST.  It should do LIST as a result of there being an error
from CREATE ... to determine if the error was because the folder had
been created by other than the MUA.


> If I were a programmer, #1 would definitely be the easiest to do.  Then I
> wouldn't have to care WHY the CREATE failed, I just show an error message no
> matter what.

But #2 is not really harder.  It's another step.  I don't think of
such logic has "harder".  To me, "hardness" of programming is the
difficulty level of figuring out what algorithm to use ... e.g. what
works and is expected to work.

I would do #2.  If as a programmer I was trying to make it easier, I'd
just not write any of it at all.  When I do programming, though, I
consider that the effort to meet reasonable human expectations is part
of the job/project.  If the developer believes humans expect to not be
able to get to a folder because it had previously been created by
something else, it should at least be informative ... "Sorry, you
cannot access folders that were created by other than you, without
restarting the client".  It's just so much simpler, even with the need
to do a whole LIST request, to give the human the realistic
expectation of seeing the folder show up after a folder creation
dialog, regardless if something else created it first.


> So in answer to the question in the subject, "Is this really a user agent
> issue?" Yes.  The server is doing nothing wrong according to protocol.

I really didn't think it was.  But I was wondering if there was some
possibility the IMAP protocol had a limitation that completely
prevented this (e.g. it wouldn't be in the LIST response, either, or
LIST is only allowed once when connecting, or whatever).  It appears
IMAP is a minimal but reasonable protocol, and provides sufficient
means for MUA logic to be reasonable, and Evolution fell short of
that.  I wanted to be sure that assumption was correct.

-- 
sHiFt HaPpEnS!


More information about the dovecot mailing list