Re: [imapext] a very simple little imap extension, really quite magnificently simple

[Jan Kundrát <[e-mail]>]

On Friday, 25 April 2014 18:57:38 CEST, Arnt Gulbrandsen wrote:
> Storing MSNs persistently so you don't have to recompute at 
> session start (and at the same time supporting simultaneous 
> sessions) was simply too difficult for me.

Given that you already have to track UIDs, I find it hard that it is 
expensive to take a look at the size of their set.

> The client cannot send BAD.
>
> The server does send BAD when it receives a BAD from the client.

The draft also says that the server should return a strange number when it 
would otherwise return a MSN. I object to that. In my opinion the server 
should signal this in a drastic way, including terminating the session if 
everything else fails. Sending back a mock-up MSN is about as evil as one 
could go in my book.

>> Given that this extension disables EXISTS, you need soemthing 
>> like ARRIVED [1]. This change on its own will complicate this 
>> dratf a lot.
>
> Why? What's wrong with UIDNEXT?

The fact that you can have gaps in UID range. The draft assumes that UIDs 
are allocated by adding one the the previous UID. Your whole scheme falls 
apart when this requirement does not hold. That requirement is not 
documented anywhere in the draft.

If the UIDs are not allocated consequently, and the highest UID right now 
is 12345, what does the following mean:

	* OK [UIDNEXT 12500] guess it

>> Also, what about STATUS and querying the offset of first 
>> message having a certain property through that? Or even STATUS 
>> EXISTS?
>
> I don't think that matters.
>
> If a client issues STATUS EXISTS, it kills any performance 
> benefit it got by issuing ENABLE UIDONLY. That's a problem for 
> the client, but not an interop problem, so nothing that requires 
> rules here.

So this is an extension whose benefit is immediately neutralized by a 
client which wants to show the user the total number of messages. To me, 
that sounds like a very basic operation.

>>> The server MUST respond with BAD to any command that uses an MSN,
>> 
>> Add a requirement for [CLIENTBUG], please. We have these 
>> response codes for a reason.
>
> Do any other RFCs require CLIENTBUG? (Not suggest, or show in 
> examples. Require.)

I'm not sure how that is relevant. This proposal is about designing an 
extension which radically changes how IMAP operates. Why not at least 
*mandate* a machine readable way of saying "hey client, you've just shot 
yourself in the foot"?

>> And the client doesn't know how many messages are in the 
>> mailbox anymore. That's a rather radical change. I don't like 
>> it at all, it's a nice safeguard to detect broken sync and this 
>> extension takes it away.
>
> Not knowing how many messages there are is a necessary effect 
> of this. It's not an accidental problem, it's necessary.
>
> The point of this is to stop counting messages. If you stop 
> counting, you don't know (at least not precisely) how many you 
> have. It's as simple as that.

OK, at this point I cannot imagine how such a client is supposed to work 
*at all*. Let's start with a blank state. The client knows nothing about 
the mailbox. It opens it and presumably wants to show a list of messages to 
the user. What is the client supposed to do now?

What if it wants to show just a subset of the mailbox, perhaps last 1k 
items (actually it doesn't have to be 1k, anything between 500 and 3000 is 
probably fine -- it needs *something*, but not the full 4M mailbox). How to 
achieve that?

What happens when a mail arrives?

How is a resynchronization after being offline for a while going to look 
like?

My answers and comments to the rest of your mail are very much dependant on 
how you propose the client to behave. I can imagine that I have all sorts 
of assumptions because I know how my client works. You might be coming from 
a different background. So I'm interested in seeing how the proposed mode 
of operation is supposed to actually work. I just don't get it now.

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/