Subject: [lemonade]About "Avoiding Duplicates"

From: Lingyan Wu <[email-masked]>
Date: Fri, 25 Aug 2006 11:27:50 +0800

Hi All,

I have some questions as follows:

Questions 1: 

A message appearing in more than one vfolders may lead to duplicate retrieval of such a message.

Why will "appearing in more than one vfolders" lead to "duplicate retrieval"? What's the direct reason?

I have seen all of the emails talking about the question but I still think it's very strange.

If more than one notifications (corresponding to the message appearing in different vfolders) for the same message lead to "duplicate retrieval", server can solve the problem by only sending one notification for the same message.

If client downloads the message from one vfolder (actually it exists in the backing mailbox), it will be tagged "SEEN" or some other tag indicating that the message has been downloaded in all the folders that the message appears in, so the problem can be resolved.

Some other reasons could be listed here.

Questions 2: 

That a message appears, disappears and reappears in a VFOLDER may result in unnecessary duplication of message on a client and may interfere with notification mechanisms.

Why will it lead to such results?

The server should know the message in the backing mailbox has been downloaded or notified.

Maybe the server itself can resolve "Avoiding Duplicates" .

Best Regards,
Lingyan
Huawei Technologies Co., Ltd. 
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: "Ben Last" <[email-masked]>
Date: Fri, 25 Aug 2006 07:57:20 +0100

>From: Lingyan Wu [mailto:[email-masked]] 
>Sent: 25 August 2006 04:28
>If more than one notifications (corresponding to the message appearing
in different vfolders) for the same message
>lead to "duplicate retrieval", server can solve the problem by only
sending one notification for the same message.

Notifications are only one way in which a client is advised of the
existence of a message.  The EXISTS count also implies it, and certainly
our client will use both the EXISTS responses to SELECT commands as well
as notifications to keep the list of messsages per mailbox up to date.

>If client downloads the message from one vfolder (actually it exists in
the backing mailbox), it
>will be tagged "SEEN" or some other tag indicating that the message has
been downloaded in all
>the folders that the message appears in, so the problem can be
resolved.

That assumes only one client.  A Lemonade server is very likely to have
multiple clients accessing the same account (set of mailboxes), so the
"tag" would need to be client-specific. Also, adding a tag means that
clients need to be extended to handle that tag, and the tag needs to be
standardized, etc.
Also, this may not solve the problem; tagging a message as "seen"
doesn't allow the client to spot the same message in all other
mailboxes/vfolders in which it appears.  The problem is in spotting the
fact that message A in vfolder X is a duplicate of message B in vfolder
Y.

>That a message appears, disappears and reappears in a VFOLDER may
result in unnecessary duplication
>of message on a client and may interfere with notification mechanisms.

Because when a message appears in a vfolder it is given a UID; if it
then disappears and reappears it would be given a new UID.  The UIDs
would be allocated within the VFOLDER and not be the UIDs from the
underlying mailboxes, because otherwise the semantics of UIDs would be
broken (that's my understanding; I welcome corrections on this or any
other point!).

I think the key point here (and this applies to your comments about
question 2 also) is that vfolders appears as if they are standard
mailboxes.  Thus the client treats them as such, and must also make the
assumption that a message in one mailbox is distinct from all other
messages in other mailboxes.  The proposed VFOLDER extension includes no
way to allow a client to see that one message is in fact a duplicate of
another.

Regards
Ben
EMCC Software Ltd

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Aug 2006 09:03:39 +0100

> still think it's very strange.
In IMAP, a message can be uniquely identified by a triplet of 
(mailbox path, UIDVALIDITY, UID). Whenever a message is copied by a 
third party - including the implicit copy by a virtual mailbox 
implementation - it appears, to the client, as an entirely new 
mailbox - there is no reliable mechansim by which the client can 
identify the message as being previously known - or also known - by 
any other triplet than the one the client sees.

Unfortunately, the Message-Id field doesn't quite identify the 
message - you may get two copies of this message, for instance - the 
one sent to the list, and the one sent directly to you. The one sent 
to the list will have additional metadata present in the List-* 
fields, and also it'll have the "lemonade mailing list" information 
appended to the bottom.

Of course, the triplet only identifies a message on a single server - 
really, there's more information than that, like the server's name, 
it's port number, etc. This is essentially encompassed into an IMAP 
URL. Copying a message gives it a new URL, but there's no method to 
find the original, nor is there any method to find out if there even 
was one.

> If more than one notifications (corresponding to the message 
> appearing in different vfolders) for the same message lead to 
> "duplicate retrieval", server can solve the problem by only sending 
> one notification for the same message.
> 
> 
Yes, but the notification would then only point to one message - 
conceptually, within IMAP, there is no such thing as a message in two 
mailboxes.

> If client downloads the message from one vfolder (actually it 
> exists in the backing mailbox), it will be tagged "SEEN" or some 
> other tag indicating that the message has been downloaded in all 
Not quite - for resynchronization operations (as opposed to online 
reading), flags are left unchanged by downloading the message. Even 
if this were not the case, there is no way to tell what data relates 
to the message you've apparently already read.

FWIW, I do have a bit of a plan here:

1) Assign a unique identifier to all mailboxes on a server. This 
unqiue identifier is essentially a shorthand for (mailbox path, 
UIDVALIDITY), except that should a folder be renamed, it will be 
preserved. This allows clients to shorten the triplet to a 2-tuple 
(mailbox id, UID).

2) All messages acquire this 2-tuple when they first enter the IMAP 
server, whether via delivery or via APPEND. This 2-tuple is preserved 
across COPY.

3) The 2-tuple can be read via a FETCH operation that will only 
return the 2-tuple when the mailbox id differs from the current 
mailbox id - that is, it'll only be shown for messages which have 
been copied or otherwise duplicated with the knowledge of the IMAP 
server.

This last is a bit of a hack, I admit, but it's one that eliminates 
the overhead of retrieving the data when it's mostly redundant. It's 
never redundant for virtual mailboxes, of course. I was hoping to 
re-use the UIDVALIDITY as a mailbox id, but Philip Guenther pointed 
out this won't work in all cases.

> result in unnecessary duplication of message on a client and may 
> interfere with notification mechanisms.
> 
I think Ben Last answered this sufficiently well that I've nothing to 
add.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Ben Last" <[email-masked]>
Date: Fri, 25 Aug 2006 09:24:35 +0100

From: Dave Cridland [mailto:[email-masked]] 
Sent: 25 August 2006 09:04
>preserved. This allows clients to shorten the triplet to a 2-tuple 

This I like very much; it also helps to solve the potentially very
expensive resynchronization/download currently incurred by renaming of a
mailbox.  It could also help to identify "special" mailboxes, if there
were some agreement on reserved identifiers for certain special
mailboxes.

>server, whether via delivery or via APPEND. This 2-tuple is preserved 
Hang on; doesn't that imply that a message can be copied to another
mailbox, but keep the id of the mailbox in which it first appeared?  If
so, that means that nearly all messages would end up with the mailbox id
of the INBOX, surely?

>been copied or otherwise duplicated with the knowledge of the IMAP 
Interesting: presumably a SEARCH could also do this?

I guess this has already been considered, but if we're adding new
attributes (like this 2-tuple) to messages, why not just allocate a
unique id to each message on arrival, and preserve that over COPY?  Then
that id can serve to allow identification of individual messages as
duplicates between vfolders or mailboxes?  Effectively this is what
you're doing, but with a 2-tuple.

>out this won't work in all cases.
There's at least one server I'm aware of that can change the UIDVALIDITY
of mailboxes in response to (what I consider) quite common/low-level
operations, incurring a severe re-synchronization/download penalty for
our client.  Plus, as far as I can tell from a quick re-reading of
RFC3501, there's no reason that UIDVALIDITY values currently need to be
unique across mailboxes.

Regards
Ben
EMCC Software Ltd

---

From: Randall Gellens <[email-masked]>
Date: Fri, 25 Aug 2006 17:56:18 -0700

> retrieval"? What's the direct reason?

A client is likely to download message in all mailboxes that is 
synchronizes.  It can't tell that message A in mailbox 1 is the same 
as message B in mailbox 2.

> one notification for the same message.

How would the server decide for which mailbox to send the 
notification?  Also, clients download messages when they SELECT 
mailboxes.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
The ignorance of how to use new knowledge stockpiles exponentially.
                                                --Marshall McLuhan

---

From: Lingyan Wu <[email-masked]>
Date: Sat, 26 Aug 2006 11:41:51 +0800

----- Original Message ----- 
From: "Ben Last" <[email-masked]>
To: "Lingyan Wu" <[email-masked]>; <[email-masked]>
Sent: Friday, August 25, 2006 2:57 PM
Subject: RE: [lemonade]About "Avoiding Duplicates"

>fact that message A in vfolder X is a duplicate of message B in vfolder

[Lingyan]--------------------------------------------------
I didn't assumes only one client but just one user with one or more clients 
(devices).
If I download one message through one client, I also want the message
appears "having to be downloaded" to other clients.
If I download one message from one vfolder, I also want the same message in 
another vfolder appears  "having to be downloaded" .
After all, all the messages in vfolders are just "link" of the actual 
messages in the backing mailbox, right?
Could the statuses (or flags)  of a message in different vfolders be 
different or not? Maybe it's the key question.

>way to allow a client to see that one message is in fact a duplicate of
[Lingyan]----------------------------------------------------------------
Does it mean that the message appearing in different vfolders (actually only 
"message link" and some related information, right? ) should be dealt with 
independently and never impact each other including flags?
If the flags of the same message keep the same in all of the vfolders where 
it appears... what will happen?

Regards
Lingyan

---

From: Lingyan Wu <[email-masked]>
Date: Sat, 26 Aug 2006 11:45:10 +0800

----- Original Message ----- 
From: "Dave Cridland" <[email-masked]>
To: "Lingyan Wu" <[email-masked]>
Cc: "Enhancements to Internet email to support diverse service enivronments" 
<[email-masked]>
Sent: Friday, August 25, 2006 4:03 PM
Subject: Re: [lemonade]About "Avoiding Duplicates"

> In IMAP, a message can be uniquely identified by a triplet of (mailbox 
> path, UIDVALIDITY, UID). Whenever a message is copied by a third party - 
> including the implicit copy by a virtual mailbox implementation - it 
> appears, to the client, as an entirely new mailbox - there is no reliable 
> mechansim by which the client can identify the message as being previously 
> known - or also known - by any other triplet than the one the client sees.

[Lingyan]------------------------------------
The same point just as in the last reply email i sent: if the flags of the 
same message keep the same all of the time in all vfolders where it appears, 
the user will know he has seen or downloaded or been notified the message in 
another vfolder (or through another client). The server should know what has 
happened to the message.

>
> Unfortunately, the Message-Id field doesn't quite identify the message - 
> you may get two copies of this message, for instance - the one sent to the 
> list, and the one sent directly to you. The one sent to the list will have 
> additional metadata present in the List-* fields, and also it'll have the 
> "lemonade mailing list" information appended to the bottom.
[Lingyan]----------------------
I agree.
> really, there's more information than that, like the server's name, it's 
> port number, etc. This is essentially encompassed into an IMAP URL. 
> Copying a message gives it a new URL, but there's no method to find the 
> original, nor is there any method to find out if there even was one.
>
[Lingyan]---------------------------------
Messages appearing in different vfolders are just "Links" of the actual 
messages in the backing mailbox, right? The server could get the original 
mailbox and UID of the message from "mapping record". Maybe it is not like 
COPY. If i misunderstand you, please correct me.
>
>> If more than one notifications (corresponding to the message appearing in 
>> different vfolders) for the same message lead to "duplicate retrieval", 
>> server can solve the problem by only sending one notification for the 
>> same message.
>>
>>

[Lingyan]--------------------------------------------
What you means is that one notification points to one actual message even if 
the message appears in different vfolders, right?
E.g. If a message arrives and appears in two vfolders (e.g. Lemonade & 
CompanyX)
(and the user has set that all the messages appearing in the two vfolders 
should
be notified ), the server only sends one notification for a "lemonade 
mailing list" message coming from [email-masked] .

>> the backing mailbox), it will be tagged "SEEN" or some other tag 
>> indicating that the message has been downloaded in all the folders that 
>> the message appears in, so the problem can be resolved.
>>
>>
> reading), flags are left unchanged by downloading the message.
[Lingyan]---------------------------------
Unchanged? Is it possible to set a flag meaning that the message has been 
downloaded or not? I think it's useful.

>Even if this were not the case, there is no way to tell what data relates 

> 1) Assign a unique identifier to all mailboxes on a server. This unqiue 
> identifier is essentially a shorthand for (mailbox path, UIDVALIDITY), 
> except that should a folder be renamed, it will be preserved. This allows 
> clients to shorten the triplet to a 2-tuple (mailbox id, UID).
>
> 3) The 2-tuple can be read via a FETCH operation that will only return the 
> 2-tuple when the mailbox id differs from the current mailbox id - that is, 
> it'll only be shown for messages which have been copied or otherwise 
> duplicated with the knowledge of the IMAP server.
>
> This last is a bit of a hack, I admit, but it's one that eliminates the 
> overhead of retrieving the data when it's mostly redundant. It's never 
> redundant for virtual mailboxes, of course. I was hoping to re-use the 
> UIDVALIDITY as a mailbox id, but Philip Guenther pointed out this won't 
> work in all cases.
>
>> Questions 2: That a message appears, disappears and reappears in a 
>> VFOLDER may result in unnecessary duplication of message on a client and 
>> may interfere with notification mechanisms.
>>
> I think Ben Last answered this sufficiently well that I've nothing to add.
>
> Dave.
> --

---

From: Lingyan Wu <[email-masked]>
Date: Sat, 26 Aug 2006 11:48:38 +0800

----- Original Message ----- 
From: "Randall Gellens" <[email-masked]>
To: "Lingyan Wu" <[email-masked]>; <[email-masked]>
Sent: Saturday, August 26, 2006 8:56 AM
Subject: Re: [lemonade]About "Avoiding Duplicates"

> synchronizes.  It can't tell that message A in mailbox 1 is the same as 
> message B in mailbox 2.

[Lingyan]-----------------------------------------------------------------
I'll give the same answer and question with my other reply emails.
Assume that the flags of the same message keep the same in all of the 
vfolder where it appears and there is such a flag meaning that the message 
has been downloaded or not.
If a client has downloaded the message from a vfolder ,the flag of the 
message in all of the vfolder where it appears as well as the backing 
mailbox will be changed , and the server/client/user will know what has 
happend to the message so "duplicate retrieval" could be avoided.

>> in different vfolders) for the same message lead to "duplicate 
>> retrieval", server can solve the problem by only sending one notification 
>> for the same message.
>
> How would the server decide for which mailbox to send the notification? 
> Also, clients download messages when they SELECT mailboxes.

[Lingyan]-------------------------------------------------------------------------
I think user could set that all the messages appearing in certain vfolders 
should be notified.

---

From: Randall Gellens <[email-masked]>
Date: Mon, 28 Aug 2006 14:12:26 -0700

At 11:41 AM +0800 8/26/06, Lingyan Wu wrote:
>  If I download one message from one vfolder, I also want the same 
> message in another vfolder appears  "having to be downloaded" .
>  After all, all the messages in vfolders are just "link" of the 
> actual messages in the backing mailbox, right?
>  Could the statuses (or flags)  of a message in different vfolders 
> be different or not? Maybe it's the key question.

I think there are two issues here:

There is no standard way in IMAP for a message to be marked as 
'downloaded'.  A client can use a custom flag for this if the server 
supports custom flags.  However, other clients won't know what the 
flag means.

IMAP does have a standard \Seen flag, which might provide what you're 
looking for.  Many clients use this flag to know how to present the 
message in the UI's listing of messages within a mailbox.  If the 
flag is not set, the client presents the message as being 'new' or 
'unseen'.  If the flag is present, the client shows the message's 
status as 'read'.  For example, in Eudora there is a big dot in the 
'status' column of the message listing for messages that have not 
been seen.

IMAP also has a \Recent flag, but this is probably not what you want.

At 11:45 AM +0800 8/26/06, Lingyan Wu wrote:

>  The same point just as in the last reply email i sent: if the flags 
> of the same message keep the same all of the time in all vfolders 
> where it appears, the user will know he has seen or downloaded or 
> been notified the message in another vfolder (or through another 
> client). The server should know what has happened to the message.

I think this goes to the central issue regarding vmailbox, views, 
contexts, and similar facilities that are now being discussed or have 
been proposed in the past:

>  question 2 also) is that vfolders appears as if they are standard

If the facility uses virtual mailboxes that appear as regular 
mailboxes, then a message which exists in a physical mailbox and also 
in one or more virtual mailboxes will appear to the client as 
multiple messages.

However, if the facility is a form of searching or sub-mailbox, then 
the client can know that the message exists elsewhere.

I don't think the group has picked one approach over the other as yet.

>  Unchanged? Is it possible to set a flag meaning that the message 
> has been downloaded or not? I think it's useful.

There is not currently a standard IMAP flag that means the message 
has been downloaded, but there is a flag that indicates the message 
has been seen.  Do you really want a client that will only download 
messages that no other client has yet downloaded?  That seems 
strange, since if you see a message on your desktop you will not see 
it on your phone.

-------------- Randomly-selected tag: ---------------
Cabbage:  A familiar kitchen-garden vegetable about as large and wise
as a man's head.

---

From: Lingyan Wu <[email-masked]>
Date: Tue, 29 Aug 2006 11:04:57 +0800

Thanks for your reply!
Inline.

----- Original Message ----- 
From: "Randall Gellens" <[email-masked]>
To: "Lingyan Wu" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 29, 2006 5:12 AM
Subject: Re: [lemonade]About "Avoiding Duplicates"

>>  If I download one message from one vfolder, I also want the same message 
>> in another vfolder appears  "having to be downloaded" .
> supports custom flags.  However, other clients won't know what the flag 
> means.
>
> message in the UI's listing of messages within a mailbox.  If the flag is 
> not set, the client presents the message as being 'new' or 'unseen'.  If 
> the flag is present, the client shows the message's status as 'read'.  For 
> example, in Eudora there is a big dot in the 'status' column of the 
> message listing for messages that have not been seen.
>
[Lingyan]---------------------------
Does downloading a message or sending a notification for the arrival of the 
messge not affect any flag of the message?
Another simple question:
What data (corresponding a certain message) are there in a vfolder? (UID, 
flags, link of the actual message)?
Maybe the flags of the same message (e.g. \Seen,\Answered etc) could keep 
the same in different vfolders where it appears, so that the server/user 
could find what had happened to the message to determin what to do.

>>  The same point just as in the last reply email i sent: if the flags of 
>> the same message keep the same all of the time in all vfolders where it 
>> appears, the user will know he has seen or downloaded or been notified 
>> the message in another vfolder (or through another client). The server 
>> should know what has happened to the message.
>
> contexts, and similar facilities that are now being discussed or have been 
> proposed in the past:
>
> If the facility uses virtual mailboxes that appear as regular mailboxes, 
> then a message which exists in a physical mailbox and also in one or more 
> virtual mailboxes will appear to the client as multiple messages.
>
> However, if the facility is a form of searching or sub-mailbox, then the 
> client can know that the message exists elsewhere.
>
>>  Unchanged? Is it possible to set a flag meaning that the message has 
>> been downloaded or not? I think it's useful.
>
> There is not currently a standard IMAP flag that means the message has 
> been downloaded, but there is a flag that indicates the message has been 
> seen.  Do you really want a client that will only download messages that 
> no other client has yet downloaded?  That seems strange, since if you see 
> a message on your desktop you will not see it on your phone.
>
[Lingyan]-------------------------------------------
I want such a flag for the following reason:
A message appearing in more than one vfolders:
If a client downloads the message from one vfolder, the message will appears 
"downloaded" in all of the vfolders where it appears as well as the backing 
mailbox, so that the user could find that the same message has been 
downloaded and could determine to download the message or not.

Another simple question:
Is there a flag or record showing that the arrival of a message has been 
notified to the client? If not, maybe there will be multi-notifications for 
one message appearing in more than one important vfolders. 
Multi-notifications may lead to duplicate retrieval of such a message if the 
client retrive messages without user interaction.

---

From: Abhijit Menon-Sen <[email-masked]>
Date: Tue, 29 Aug 2006 10:52:13 +0530

At 2006-08-29 11:04:57 +0800, [email-masked] wrote:
>
> What data (corresponding a certain message) are there in a vfolder?
> (UID, flags, link of the actual message)?

IMAP has no way to express a "link to the actual message". As far as the
client is concerned, the message in the vfolder *is* the actual message,
and there's no direct way to differentiate between instances of the same
message appearing in different vfolders.

(So, to answer your question, a vfolder contains exactly the same data
for one message as any other mailbox would.)

-- ams

---

From: Lingyan Wu <[email-masked]>
Date: Tue, 29 Aug 2006 13:50:23 +0800

Yes. Just as what you said, as far as the client is concerned, vfolder looks 
and behaves like a  real IMAP4 folder, but it does not contain any messages 
itself.

---

From: Philip Guenther <[email-masked]>
Date: Tue, 29 Aug 2006 00:22:06 -0600

On Tue, 29 Aug 2006, Lingyan Wu wrote:
>"Randall Gellens" <[email-masked]> wrote:
...
>> There is not currently a standard IMAP flag that means the message has been 
>> downloaded, <...>
>
> I want such a flag for the following reason: A message appearing in more 
> than one vfolders: If a client downloads the message from one vfolder, 
> the message will appears "downloaded" in all of the vfolders where it 
> appears as well as the backing mailbox, so that the user could find that 
> the same message has been downloaded and could determine to download the 
> message or not.

So, the flag by itself would *not* solve the problem.  Telling the client 
that it had already downloaded the message doesn't help unless the client 
can figure out where that data is.  That is, the client would need some 
way to know that the message with UID N in mailbox A is the message as the 
one with UID M in mailbox B.

BUT, that once you tell the client that, _it_ can figure out whether it 
has already downloaded the message and the flag is completely pointless.

Indeed, the flag would be misleading: the server has no way of knowing 
whether the client decided to flush the previously downloaded instance of 
the message from its cache.  (Requiring the client to tell the server that 
it dropped something from its cache would be utterly ridiculous: cost with 
no benefit!)

> notified to the client?

"the client"?  _Which_ client?  My INBOX is often concurrently selected by 
two distinct clients, one of which changes IP fairly often.  I 
occasionally select it in another program running on the same machine as 
one of the above.  This flag or record will have to some how be 
"per-client" in some way, so that each client have its own view of which 
messages have been downloaded, no?  How is the server supposed to do that?

So, the answer to your question is "no, no such flag or record exists on 
the server".

> If not, maybe there will be multi-notifications for one message 
> appearing in more than one important vfolders.

That's a completely separate issue from the above.  Even if there was _no_ 
way in IMAP itself to tell a client that two messages were "the same", we 
could still have a notification protocol that coalesced notification for 
distinct folders.

Philip Guenther

---

From: Randall Gellens <[email-masked]>
Date: Tue, 29 Aug 2006 10:40:09 -0700

At 11:04 AM +0800 8/29/06, Lingyan Wu wrote:

>  Does downloading a message or sending a notification for the 
> arrival of the messge not affect any flag of the message?

Downloading all or part of a message may or may not set the \Seen 
flag, but this is under control of the client.  Probably most clients 
today are designed to be used off-line.  So the client maintains a 
cache of messages in mailboxes.  When the client fetches all or part 
of a message, it usually does so without setting the \Seen flag.  The 
client displays the status of the message in the message listing for 
the mailbox.  If the \Seen flag was already set, the client shows the 
message as having been seen or read.  Otherwise it shows the message 
as being unread.  If the user opens the message, the client sets the 
\Seen flag when it next connects to the server.

Note that this way of operating is a design decision for the client, 
it is not a requirement of IMAP.

>  Maybe the flags of the same message (e.g. \Seen,\Answered etc) 
> could keep the same in different vfolders where it appears, so that 
> the server/user could find what had happened to the message to 
> determin what to do.

Since a vmailbox doesn't physically exist, flags may or may not be 
kept in synch.  That's a design decision for the vmailbox facility.

>> has been downloaded, but there is a flag that indicates the 
>> message has been seen.  Do you really want a client that will only 
>> download messages that no other client has yet downloaded?  That 
>> seems strange, since if you see a message on your desktop you will 
>> not see it on your phone.
>>
>  If a client downloads the message from one vfolder, the message 
> will appears "downloaded" in all of the vfolders where it appears 
> as well as the backing mailbox, so that the user could find that 
> the same message has been downloaded and could determine to 
> download the message or not.

Two points:

(1) It sounds to me that you want a flag that means the message has 
been seen, not a flag that means the message has been downloaded.  I 
say this because I assume that a user will be interested in a message 
based on if he or she has already read it or not, instead of based on 
if some client has downloaded it or not.

(2) It is a client design issue when to download the message and how 
much of it to download at any point.  Often this is settable by the 
user.

Sometimes the client will download basic information about the 
message in order to populate the message listing for a mailbox.  This 
may include the To, From, Subject, and Date headers plus the body 
structure.  That allows the client to fill in the most common columns 
of the message listing, including if the message has attachments.

Sometimes clients will also fetch other headers and maybe also one or 
more body parts.

So, in some cases the message body will not be downloaded by the 
client until the users specifically asks for it.  In other cases the 
client will download it in advance, so the user can see it at any 
point, even when not connected.

-------------- Randomly-selected tag: ---------------
yoin (yoh-EEN; Japanese; noun): experiential reverberation that
continues to move one long after the initial external stimulus
has ceased.

---

From: Mark Crispin <[email-masked]>
Date: Tue, 29 Aug 2006 17:56:50 -0700 (Pacific Daylight Time)

On Tue, 29 Aug 2006, Randall Gellens wrote:
> Probably most clients today are 
> designed to be used off-line.  So the client maintains a cache of messages in 
> mailboxes.

I agree that this is the case today.  I hope that it is not always the 
case.

In particular, as connectivity continues to be increasingly faster, more 
ubiquitous, and less costly, I hope to see more online IMAP clients (which 
do not keep state on the client).

This includes mobile clients.  Most mobile client web browsers these days 
are online.  I hope to see this trend occur with message browsers.  Of 
course, some further advances are necessary, but I think (hope!) that 
they're coming.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: Randall Gellens <[email-masked]>
Date: Tue, 29 Aug 2006 19:06:20 -0700

At 5:56 PM -0700 8/29/06, Mark Crispin wrote:

>>  Probably most clients today are designed to be used off-line.  So 
>> the client maintains a cache of messages in mailboxes.
>
>  I agree that this is the case today.  I hope that it is not always the case.
>
>  In particular, as connectivity continues to be increasingly faster, 
> more ubiquitous, and less costly, I hope to see more online IMAP 
> clients (which do not keep state on the client).

I think it is likely that for the near future there will continue ti 
be situations where Internet access is not available, even if in 
general Internet access becomes faster, cheaper, and more widely 
available.  It is frustrating to be unable to use email just because 
network access isn't immediately available.

>  This includes mobile clients.  Most mobile client web browsers 
> these days re online.

I have a hard time imagining how an off-line web browser would be 
useful.  I suppose it would cache popular sites or personal 
favorites, but still, web browsing is based on being able to 
immediately follow links wherever they may lead.  It seems to me to 
be very different from email, where messages are directed to you.

>  I hope to see this trend occur with message browsers.  Of course, 
> some further advances are necessary, but I think (hope!) that 
> they're coming.

Of course, in the old days all mail readers were online only.

-------------- Randomly-selected tag: ---------------
A successful tool is used to do something undreamed of by its author.
                                                           --Johnson