On 12-feb-04, at 22:33, Hector Santos wrote:
For instance, the user may be connecting over a slow link and not want
to download everything just yet, or the user uses several computers to
read mail and wants to make sure each of those has a copy before the
message is removed from the server. A way to track how many clients
are
supposed to get copies of a message and how many have already would be
useful here.
In other words, it requires a redesign where the server requires
multiple
"received" flags in the header.
Yes.
One that says he received it at the system
level and one that related to the human and presented as being
received.
Ok, that would be the next step. Do we need this, and do we have any
reasonable way to achieve it? Remember that humans make for a lousy
platform for implementing protocols.
In our system, we called the "Preview Mail" problem because that is
basically what a system will need to do if he doesn't add a multiple
receive bit concept to identify the different methods a message was
previewed. One that allows a message to be redownload and one that
tells the system the user did receive the message. The user can't lie
now
Just because the computer downloaded the message you don't know if the
user read it. Just because the message was on the screen you don't know
that the user was looking... I don't think it's _possible_ to make a
system where the only two possible states are "the recipient hasn't
read the message" and "the recipient has read the message and the
sender knows this".