2. Take the inbox/folder name and fetch the header detatils of each message(recipient name, subject, internal date, flags) from server. Store this information in a temporary memory (cache). Display this information immediatly to user.
I presume you have some idea of the screen size of the device you're working with. Only fetch enough headers to fill one or two screens. Pre-fetch more in the background, if the device allows you to run background processing, up to the amount you're willing to cache.
3. User will select any one of these messages. After selection of message, I will take the required message header information and i will flush the remaining messages header information.
Bad Idea; don't flush your cache. Keep the cache to a reasonable size, and retain it.
So, putting these two together, if the user selects a mailbox with, say, 2000 messages in it, and the device's screen has 20 lines, maybe you fetch 20 to 40 message headers. You get the number of messages (call it "n") in the EXISTS response from the SELECT, so then you can do "FETCH <n-19>:n FULL", for instance, to get information about the most recent 20 messages. As Timo says, it'd be a good idea here to fetch the UIDs also, and keep them in your cache.
4. I will first search for the message number based on header information. Then i will retrieve the message text from the server based on message number. I will store this information on temporory memory, i will parse this information and i will display the formatted message on the screen.
Horrible Idea; as Timo says, since you cached the UIDs in step 2, when the user selected a message you already had the UID, so now you do "UID FETCH xxx BODY[...]" to get the bits you need.
6. If user deletes that message means, i will search for message number based on header information, then i will delete that message.
"UID STORE xxx +FLAGS \Deleted"
7. In this scenario i am not sotring any mail information / folder information. Every thing is temporary. For every action i will fetch corresponding information form server and i will display on the screen.
And if you do it the way you outlined, you'll have unnecessary data transfer across what I presume to be a slow connection, and you'll make the server search for things that you already know how to find, and you'll take the risk that two messages are similar enough to be hard to tell apart.
Barry Leiba, Internet Messaging Technology ([EMAIL PROTECTED]) http://www.research.ibm.com/people/l/leiba
