Hi Nikola!
Say you have a GUI IMAP client XxX. Say you start it up and click on
the INBOX. What would you desire/expect XxX to do?
I would expect to see all mail headers in my inbox.
Well, you cannot see _all_ of your headers when you have a big mailbox
full of mails. You can only see a few of them, perhaps 20, or 50 or so.
The client theoretically would be able to clarify, how many emails it
can show to the user, depending on the height of the message list
window. Then it could just fetch only the headers of the messages, which
it can show you now.
As soon as a user scrolls, it can fetch the next few headers.
My opinion: That's fine in an Webmail Client or in a console based
client, where you only can scroll line by line or page by page.
I don't know what a graphical client should do, when a user drags the
view with the vertical window slider and scrolls up to down to up in
between 3 seconds.
The client would have to try to get all headers in 3 seconds? Or should
he just show n/a to the user until he stops? Very bad idea in my eyes.
I often scroll through my whole mailbox searching for a specific date
range or similar. I don't want to issue a search query because of that
task, that would be very non-economical.
So in my opinion: you cannot use this behavior in a graphical client.
Well, I have to believe that mulberry can do that somehow, I cannot
check that, this program and its vendor are non-existant anymore.
But I know: The smaller your bandwith to the server is, the nastier
would be the delay you have when you scroll through your folder
searching for something.
Best,
Daniel
Nikola Milutinovic schrieb:
The first time you open a large IMAP folder is not very fast, I
have to admit, but I didn't find any other comparable IMAP client
without this problem. Perhaps there are some, but I didn't try
them because of the lack of other basic email features.
This is why they aren't IMAP clients. IMAP servers make all manner
of searching, sorting, retrieval, and storage options completely
available to the client, without having to download even all the
headers. This is why Mulberry, Pine, Mutt, and Kmail are so much
faster. If TBird would just do that instead of insisting on
blindly attempting to download all the headers and performing all
sorting and searching on the client. TBird and most of the others
have their roots and brains seated back in the POP3 dark ages near
as I can tell and that's how they treat all mail stores. IMAP
allows the clients to easily ask for threaded views (unless you
turn the index options off or something like that) from the server,
as well as partial sets of headers in batch. This massively speeds
things up when you're on a modem, or working with large mailboxes,
or mailboxes you only occasionally open.
I must say I'm a bit lost here. I have been using and administering
Cyrus IMAP for years now, so I'm not really a new kid on the block.
Say you have a GUI IMAP client XxX. Say you start it up and click on
the INBOX. What would you desire/expect XxX to do?
I would expect to see all mail headers in my inbox.
So, how do you do that in XxX, other then fetching all mail headers?
How do you do that in Pine and Mutt?
Now, fetching it EVERY time, well, that would make me switch to
another client. So, caching comes in. Of course, that introduces the
issue of synchronization, not just for new mails, but also for mails
deleted outside that client. I'm not sure how TB handles that.
What is your "modus operandi" in Mutt or Pine for this? If I
understand correctly, you just make IMAP queries to the server and
display what you desire. Hmm, call me lazy, but I would mark such a
feature in TB unwelcome. When I click on the INBOX, I expect to see
it's contents. That is the semantics I'm used to, when I "click on a
folder". Is this semantic somehow confronted to the root philosophy
of IMAP client/server?
Furthermore, if TB is implementing those semantics in IMAP protocol
in an undesirable fashion, what should it do to become desirable
again?
And don't get me wrong, there were a couple of features in TB that
made me reach into my "dictionary of less than favourable epitets".
Like connection caching, which made my installation crash (it could
have been my mistake in not applying some patches). For that matter,
OE has a similar feature, which when turned on, made my IMAPD
processes die (something like "include this folder/account in sync on
startup" or something like that). That looked like a bug in the
server, but never mind. I didn't quite understand the need for
connection caching on a single IMAP account. It just opened up to 5
connections for each folder I opened. Well, at least it can be turned
off.
Nix.
---- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ:
http://cyruswiki.andrew.cmu.edu List Archives/Info:
http://asg.web.cmu.edu/cyrus/mailing-list.html
----
Cyrus Home Page: http://asg.web.cmu.edu/cyrus
Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu
List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
