On Fri, 22 Feb 2003, Timo Sirainen wrote:
> > Well, you stated your problem: you don't use a good IMAP client.
> That could be it. Installing and running would have to be as easy as
> sshing with putty though. Meaning you could get imapclient.exe from web
> page which you can run directly, only required configuration should be
> entering username, password and IMAP server host.
That sounds like PC Pine.
> Actually it would also need SMTP server configuration unless it acts as
> such itself. Maybe IMAP server could give some SMTP configuration hints
> to client so user wouldn't have to set those manually.
We don't have that, but we do have a way to have a remote Pine
configuration so that a user can use Pine on multiple platforms and get
your one true configuration each time.
We even have a way to do NNTP proxy via IMAP, with minimal noticable
difference between that and direct NNTP. That keeps your newsrc on the
same place too.
> So on topic summary: I'm
> not against clients doing well optimized server fetches, but I don't
> think clients failing to do so are useless crap.
In my experience, clients which make dumb mistakes such as:
1 UID FETCH 237 FLAGS
* 3 FETCH (FLAGS (\Seen) UID 237)
1 OK done
2 UID FETCH * FLAGS
* 4 FETCH (FLAGS (\Seen) UID 483)
2 OK done
4 UID FETCH 238:482 FLAGS
4 OK no messages there
will do other stupid things as well.
It gets worse. The same "UID-only" client that fails to realize that
there can't be any UIDs between a UID with sequence 3 and a UID with
sequence 4, also fails to grasp that the failure to find any UIDs in
that range means that there won't ever be any in that range, and keeps
on trying to find them.
There are clients which do UID FETCH 1:* UID repeatedly in the same
session. Some of these clients do it as a poll for new mail, since they
disregard the EXISTS response.
Then there are the clients which spawn connections for no good reason, but
that's another story.
This isn't "not doing well-optimized server fetches". This is doing
well-pessimized server fetches.
> And I still don't see
> how sequences would be inherently better for client to use than UIDs.
If you don't use sequences, then each and every cache reference requires a
lookup to locate the associated message for the UID in the cache. At
best, this is a hash. With sequences, it's an index.
If you use sequences, you know when you get an EXISTS precisely how many
new messages there are (if in fact there are any). With UID-only, you
have to do <lastuid+1>:* and woe be it to you if the server is one of the
broken ones (like Courier) which incorrectly assumes that the left side of
the : must be less than the right side.
If you use sequences, you know when you get an EXPUNGE precisely which
message was expunged (hence your request for an extra UIDEXPUNGE, which
would burden all IMAP sessions with additional traffic -- remember that
EXPUNGE can be unsolicited).
If you use sequences, your commands, especially when the sets get large,
will be much smaller than with UIDs. So will your SEARCH, SORT, and
THREAD results.
Last but not least, if you use sequences, you as a programmer are
compelled to consider silly cases (such as I indicated above), and avoid
doing them. You can't build a sequence "between, but not including, 3 and
4"; therefore you know that there's nothing to do.
With UID-only, the silliness of what you may be doing is obscured from
you, and your client ends up embarassing itself to server maintainers who
run protocol traces to answer their customers' questions as to "why is it
so slow"?
Time and time again, I hear the advocates of UID-only claim that what they
are doing is "better" or "more efficient". Time and time again, when I
see what the client does over the wire, these claims ring hollow.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
