Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views
From: Cyrus Daboo <[email-masked]>
To: Chris Newman <[email-masked]>, Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Date: Tue, 25 Apr 2000 19:32:57 -0400
List-Id: <ietf-imapext.imc.org>

--On Tuesday, April 25, 2000 4:02 PM -0700 Chris Newman 
<[email-masked]> wrote:

> Starting with this premise, the problem I see of implementing a dynamic
> view with a semi-dynamic only server is that the client would have to
> replicate the server search facility in order to know when some flag or
> annotation change notification would result in the message going out of a
> dynamic view.  A way to address that problem would be to have a
> server-supplied flag (e.g. \NOVIEW) which is set on messages that are in
> the semi-dynamic view but no longer meet the view search criteria.

Interesting idea! Actually I'm going to turn this around and explain how we 
could use a similar approach to allow a client to be semi-dynamic when the 
server is only dynamic:

1) The server implictly sets a \VIEW flag on any message that appears in a 
view, either as the direct result of a VIEW command, or as a dynamic update 
while VIEW is in effect. The \VIEW flag is never removed by the server, but 
the client may remove it itself, if so desired.

2) A client can then choose to issue a VIEW command with search criteria 
that includes matching any message with the \VIEW flag set. Thus, even if 
other properties of a message change, provided the \VIEW flag remains set, 
that message will always be in the view.

I think this would really solve the problem at hand. With the above 
behaviour, servers could be fully dynamic, whilst clients could choose 
between semi-dynamic or dyanmic behaviour by simply using the \VIEW flag. 
The only work that is required is to define the precise behaviour of the
\VIEW flag. I wouldn;t have thought implementing this flag behaviour on a 
server would be difficult.

-- 
Cyrus

Date: Tue, 25 Apr 2000 16:02:24 -0700
From: Chris Newman <[email-masked]>
Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views
To: Cyrus Daboo <[email-masked]>, Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

--On Monday, April 24, 2000 20:59 +0000 Cyrus Daboo <[email-masked]> 
wrote:
> I think there is certainly more consensus that there be only one
> mechanism, for reasons of simplicity. The question is which one.
> ...
> The issue is whether it is easier for a client to implement semi-dynamic
> with a dynamic only server, or whether it is easier to do dynamic with a
> semi-dynamic only server. I would argue the later is the case. There is
> also the issue as to which is easier for a server, so there is a
> trade-off between client and server complexity that has to be addressed
> as well.

Starting with this premise, the problem I see of implementing a dynamic 
view with a semi-dynamic only server is that the client would have to 
replicate the server search facility in order to know when some flag or 
annotation change notification would result in the message going out of a 
dynamic view.  A way to address that problem would be to have a 
server-supplied flag (e.g. \NOVIEW) which is set on messages that are in 
the semi-dynamic view but no longer meet the view search criteria.

		- Chris

content-class: urn:content-classes:message
Subject: RE: "dynamic" vs. "semi-dynamic and dynamic" views
Date: Tue, 25 Apr 2000 15:12:41 -0700
From: "Mike Gahrns" <[email-masked]>
To: "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFAF03.5FEE131E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Cyrus writes:
> My personal feeling, based on experience with client-side=20
> views, is that=20
> the semi-dynamic mode is really what users expect clients to=20
> do. But we do=20
> need to hear from other client implementors as to what they=20
> think is the=20
> right mode to use. I know other clients have a similar=20
> client-side view=20
> behaviour, and it might be worthwhile to why different modes=20
> were chosen.
*** This is an area where there is no clear right or wrong answer.
Arguments can be made for either behavior here.

Since you wanted input as to why different modes were chosen, here goes:

Microsoft clients choose the dynamic behavior since this tested better
in our usability labs. Reason's why I think it tested better are:
1) Having consistent behavior is easier to explain to users. Users tend
to like consistency. It is an easier to explain to a user that as
messages change or arrive they will be added or dropped from the view
accordingly, instead of going into the concepts of dynamic and
semi-dynamic and stating that one set of rules apply to new messages and
another to existing messages. If a user is a sophisticated enough user
to set a filtered view, then the user tends to understand the concept of
what a filter is and is not surprised that as they read messages, that
those read messages drop from their unread filtered view.  Thus since
you are dealing with a relatively advanced user, the problem of a user
being confused by "messages disappearing from my view" is relatively
rare.

2) Filters are often used by users who have a lot of mail.  When
applying a filter such as "show me only unread messages", they are great
usability benefits by continually narrowing the number of messages that
a user is dealing with as they move out of the filter criteria.
Say a user starts with 150 unread messages.  As they continue to process
and read their mail, the number of messages that they need to deal with
diminished, making it much easier for the user to choose which of the
remaining messages they want to read next.

------_=_NextPart_001_01BFAF03.5FEE131E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4344.0">
<TITLE>RE: &quot;dynamic&quot; vs. &quot;semi-dynamic and dynamic&quot; =
views</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Cyrus writes:</FONT>

<BR><FONT SIZE=3D2>&gt; My personal feeling, based on experience with =
client-side </FONT>

<BR><FONT SIZE=3D2>&gt; views, is that </FONT>

<BR><FONT SIZE=3D2>&gt; the semi-dynamic mode is really what users =
expect clients to </FONT>

<BR><FONT SIZE=3D2>&gt; do. But we do </FONT>

<BR><FONT SIZE=3D2>&gt; need to hear from other client implementors as =
to what they </FONT>

<BR><FONT SIZE=3D2>&gt; think is the </FONT>

<BR><FONT SIZE=3D2>&gt; right mode to use. I know other clients have a =
similar </FONT>

<BR><FONT SIZE=3D2>&gt; client-side view </FONT>

<BR><FONT SIZE=3D2>&gt; behaviour, and it might be worthwhile to why =
different modes </FONT>

<BR><FONT SIZE=3D2>&gt; were chosen.</FONT>

<BR><FONT SIZE=3D2>*** This is an area where there is no clear right or =
wrong answer. Arguments can be made for either behavior here.</FONT>
</P>

<P><FONT SIZE=3D2>Since you wanted input as to why different modes were =
chosen, here goes:</FONT>
</P>

<P><FONT SIZE=3D2>Microsoft clients choose the dynamic behavior since =
this tested better in our usability labs. Reason's why I think it tested =
better are:</FONT></P>

<P><FONT SIZE=3D2>1) Having consistent behavior is easier to explain to =
users. Users tend to like consistency. It is an easier to explain to a =
user that as messages change or arrive they will be added or dropped =
from the view accordingly, instead of going into the concepts of dynamic =
and semi-dynamic and stating that one set of rules apply to new messages =
and another to existing messages. If a user is a sophisticated enough =
user to set a filtered view, then the user tends to understand the =
concept of what a filter is and is not surprised that as they read =
messages, that those read messages drop from their unread filtered =
view.&nbsp; Thus since you are dealing with a relatively advanced user, =
the problem of a user being confused by &quot;messages disappearing from =
my view&quot; is relatively rare.</FONT></P>

<P><FONT SIZE=3D2>2) Filters are often used by users who have a lot of =
mail.&nbsp; When applying a filter such as &quot;show me only unread =
messages&quot;, they are great usability benefits by continually =
narrowing the number of messages that a user is dealing with as they =
move out of the filter criteria.</FONT></P>

<P><FONT SIZE=3D2>Say a user starts with 150 unread messages.&nbsp; As =
they continue to process and read their mail, the number of messages =
that they need to deal with diminished, making it much easier for the =
user to choose which of the remaining messages they want to read =
next.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BFAF03.5FEE131E--

Date: Mon, 24 Apr 2000 20:59:01 +0000
From: Cyrus Daboo <[email-masked]>
To: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views
Sender: [email-masked]

Hi Mike,
Sorry for the delay in getting back to you on this:

--On 04/07/00 10:57:46 -0700 Mike Gahrns <[email-masked]> 
wrote:

> I-D ACTION:draft-daboo-imapext-view-02.txt (fwd)At the Adelaide BOF
> several  of us brought up the fact that we were surprised that this
> latest draft  allowed for both semi-dynamic and dynamic views.   We had
> thought that at  the previous Washington D.C. BOF there was rough
> consensus that dynamic was  the way to go here.

No that was not the case: there wasn't consensus on the dynamic vs 
semi-dynamic view in Washington. It was decided to have a small 'design 
team' work on this issue and then present their suggestions/results to the 
list. For various reasons the 'design team' did not get going until about 
one month before Adelaide, and this left little time to really argue out 
this issue before the draft deadline. There was still debate between which 
of the two should be used, and whether there should only be one or both of 
them.

> Any client who wanted to expose a semi-dynamic view
> could do so easily by simply ignoring the dynamic updates from the 
server.

No - this is not simple! If messages have been removed from the server's 
view but the client wants to maintain them in its view, then there is a 
problem. The client can only refer to these messages by UID, as the VPN 
(view position number) is no longer applicable. One of the goals of VIEW is 
to remove the need for clients to maintain multiple mappings between 
different message identifiers, be they message numbers, UIDs or VPNs, to 
simplify sorting behaviour.

> I do not like the extra complexity that
> allowing both dynamic and  semi-dynamic views adds to the protocol.  And
> I know that for our particular  server implementation having both of
> these modes will add a large degree of  difficulty to our implementation.

I think there is certainly more consensus that there be only one mechanism, 
for reasons of simplicity. The question is which one.

>  It seems to me that this extra complexity is not worth the cost here, as
> the functionality could still be achieved relatively easily at the client
> without this extra complexity on the server.

The issue is whether it is easier for a client to implement semi-dynamic 
with a dynamic only server, or whether it is easier to do dynamic with a 
semi-dynamic only server. I would argue the later is the case. There is 
also the issue as to which is easier for a server, so there is a trade-off 
between client and server complexity that has to be addressed as well.

> I think one could also
> argue  that going with dynamic view only  would ultimately simplify
> client  development as well, since you no longer need to worry about what
> type of  server you are talking to.  At the Adelaide BOF, there was no
> representation  of people who wanted to see this "dual mode" of dynamic
> and semi-dynamic  views, so I said I would post to the list so that we
> could start a  discussion to resolve this issue.   Comments?

My personal feeling, based on experience with client-side views, is that 
the semi-dynamic mode is really what users expect clients to do. But we do 
need to hear from other client implementors as to what they think is the 
right mode to use. I know other clients have a similar client-side view 
behaviour, and it might be worthwhile to why different modes were chosen.

-- 
Cyrus

** Running Mulberry on LinuxPPC 2000 **

From: Mike Gahrns <[email-masked]>
To: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: "dynamic" vs. "semi-dynamic and dynamic" views
Date: Fri, 7 Apr 2000 09:57:46 -0700 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFA0BA.B5760E7C
Content-Type: text/plain;
	charset="iso-8859-1"

I-D ACTION:draft-daboo-imapext-view-02.txt (fwd)At the Adelaide BOF several
of us brought up the fact that we were surprised that this latest draft
allowed for both semi-dynamic and dynamic views.   We had thought that at
the previous Washington D.C. BOF there was rough consensus that dynamic was
the way to go here.   Any client who wanted to expose a semi-dynamic view
could do so easily by simply ignoring the dynamic updates from the server.
I do not like the extra complexity that allowing both dynamic and
semi-dynamic views adds to the protocol.  And I know that for our particular
server implementation having both of these modes will add a large degree of
difficulty to our implementation.

 It seems to me that this extra complexity is not worth the cost here, as
the functionality could still be achieved relatively easily at the client
without this extra complexity on the server.  I think one could also argue
that going with dynamic view only  would ultimately simplify client
development as well, since you no longer need to worry about what type of
server you are talking to.  At the Adelaide BOF, there was no representation
of people who wanted to see this "dual mode" of dynamic and semi-dynamic
views, so I said I would post to the list so that we could start a
discussion to resolve this issue.   Comments?

------_=_NextPart_001_01BFA0BA.B5760E7C
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>&quot;dynamic&quot; vs. &quot;semi-dynamic and dynamic&quot; views</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I-D ACTION:draft-daboo-imapext-view-02.txt (fwd)At the Adelaide BOF several</FONT>
<BR><FONT SIZE=2>of us brought up the fact that we were surprised that this latest draft</FONT>
<BR><FONT SIZE=2>allowed for both semi-dynamic and dynamic views.&nbsp;&nbsp; We had thought that at</FONT>
<BR><FONT SIZE=2>the previous Washington D.C. BOF there was rough consensus that dynamic was</FONT>
<BR><FONT SIZE=2>the way to go here.&nbsp;&nbsp; Any client who wanted to expose a semi-dynamic view</FONT>
<BR><FONT SIZE=2>could do so easily by simply ignoring the dynamic updates from the server.</FONT>
<BR><FONT SIZE=2>I do not like the extra complexity that allowing both dynamic and</FONT>
<BR><FONT SIZE=2>semi-dynamic views adds to the protocol.&nbsp; And I know that for our particular</FONT>
<BR><FONT SIZE=2>server implementation having both of these modes will add a large degree of</FONT>
<BR><FONT SIZE=2>difficulty to our implementation.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;It seems to me that this extra complexity is not worth the cost here, as</FONT>
<BR><FONT SIZE=2>the functionality could still be achieved relatively easily at the client</FONT>
<BR><FONT SIZE=2>without this extra complexity on the server.&nbsp; I think one could also argue</FONT>
<BR><FONT SIZE=2>that going with dynamic view only&nbsp; would ultimately simplify client</FONT>
<BR><FONT SIZE=2>development as well, since you no longer need to worry about what type of</FONT>
<BR><FONT SIZE=2>server you are talking to.&nbsp; At the Adelaide BOF, there was no representation</FONT>
<BR><FONT SIZE=2>of people who wanted to see this &quot;dual mode&quot; of dynamic and semi-dynamic</FONT>
<BR><FONT SIZE=2>views, so I said I would post to the list so that we could start a</FONT>
<BR><FONT SIZE=2>discussion to resolve this issue.&nbsp;&nbsp; Comments?</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BFA0BA.B5760E7C--

Date: Tue, 25 Apr 2000 19:32:57 -0400
From: Cyrus Daboo <[email-masked]>
To: Chris Newman <[email-masked]>, Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views
Sender: [email-masked]

--On Tuesday, April 25, 2000 4:02 PM -0700 Chris Newman 
<[email-masked]> wrote:

> Starting with this premise, the problem I see of implementing a dynamic
> view with a semi-dynamic only server is that the client would have to
> replicate the server search facility in order to know when some flag or
> annotation change notification would result in the message going out of a
> dynamic view.  A way to address that problem would be to have a
> server-supplied flag (e.g. \NOVIEW) which is set on messages that are in
> the semi-dynamic view but no longer meet the view search criteria.

Interesting idea! Actually I'm going to turn this around and explain how we 
could use a similar approach to allow a client to be semi-dynamic when the 
server is only dynamic:

1) The server implictly sets a \VIEW flag on any message that appears in a 
view, either as the direct result of a VIEW command, or as a dynamic update 
while VIEW is in effect. The \VIEW flag is never removed by the server, but 
the client may remove it itself, if so desired.

2) A client can then choose to issue a VIEW command with search criteria 
that includes matching any message with the \VIEW flag set. Thus, even if 
other properties of a message change, provided the \VIEW flag remains set, 
that message will always be in the view.

I think this would really solve the problem at hand. With the above 
behaviour, servers could be fully dynamic, whilst clients could choose 
between semi-dynamic or dyanmic behaviour by simply using the \VIEW flag. 
The only work that is required is to define the precise behaviour of the
\VIEW flag. I wouldn;t have thought implementing this flag behaviour on a 
server would be difficult.

-- 
Cyrus

Date: Tue, 25 Apr 2000 16:02:24 -0700
From: Chris Newman <[email-masked]>
Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views
To: Cyrus Daboo <[email-masked]>, Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Sender: [email-masked]

--On Monday, April 24, 2000 20:59 +0000 Cyrus Daboo <[email-masked]> 
wrote:
> I think there is certainly more consensus that there be only one
> mechanism, for reasons of simplicity. The question is which one.
> ...
> The issue is whether it is easier for a client to implement semi-dynamic
> with a dynamic only server, or whether it is easier to do dynamic with a
> semi-dynamic only server. I would argue the later is the case. There is
> also the issue as to which is easier for a server, so there is a
> trade-off between client and server complexity that has to be addressed
> as well.

Starting with this premise, the problem I see of implementing a dynamic 
view with a semi-dynamic only server is that the client would have to 
replicate the server search facility in order to know when some flag or 
annotation change notification would result in the message going out of a 
dynamic view.  A way to address that problem would be to have a 
server-supplied flag (e.g. \NOVIEW) which is set on messages that are in 
the semi-dynamic view but no longer meet the view search criteria.

		- Chris

content-class: urn:content-classes:message
Subject: RE: "dynamic" vs. "semi-dynamic and dynamic" views
Date: Tue, 25 Apr 2000 15:12:41 -0700
From: "Mike Gahrns" <[email-masked]>
To: "IMAP Extensions WG" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01BFAF03.5FEE131E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Cyrus writes:
> My personal feeling, based on experience with client-side=20
> views, is that=20
> the semi-dynamic mode is really what users expect clients to=20
> do. But we do=20
> need to hear from other client implementors as to what they=20
> think is the=20
> right mode to use. I know other clients have a similar=20
> client-side view=20
> behaviour, and it might be worthwhile to why different modes=20
> were chosen.
*** This is an area where there is no clear right or wrong answer.
Arguments can be made for either behavior here.

Since you wanted input as to why different modes were chosen, here goes:

Microsoft clients choose the dynamic behavior since this tested better
in our usability labs. Reason's why I think it tested better are:
1) Having consistent behavior is easier to explain to users. Users tend
to like consistency. It is an easier to explain to a user that as
messages change or arrive they will be added or dropped from the view
accordingly, instead of going into the concepts of dynamic and
semi-dynamic and stating that one set of rules apply to new messages and
another to existing messages. If a user is a sophisticated enough user
to set a filtered view, then the user tends to understand the concept of
what a filter is and is not surprised that as they read messages, that
those read messages drop from their unread filtered view.  Thus since
you are dealing with a relatively advanced user, the problem of a user
being confused by "messages disappearing from my view" is relatively
rare.

2) Filters are often used by users who have a lot of mail.  When
applying a filter such as "show me only unread messages", they are great
usability benefits by continually narrowing the number of messages that
a user is dealing with as they move out of the filter criteria.
Say a user starts with 150 unread messages.  As they continue to process
and read their mail, the number of messages that they need to deal with
diminished, making it much easier for the user to choose which of the
remaining messages they want to read next.

------_=_NextPart_001_01BFAF03.5FEE131E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.0.4344.0">
<TITLE>RE: &quot;dynamic&quot; vs. &quot;semi-dynamic and dynamic&quot; =
views</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Cyrus writes:</FONT>

<BR><FONT SIZE=3D2>&gt; My personal feeling, based on experience with =
client-side </FONT>

<BR><FONT SIZE=3D2>&gt; views, is that </FONT>

<BR><FONT SIZE=3D2>&gt; the semi-dynamic mode is really what users =
expect clients to </FONT>

<BR><FONT SIZE=3D2>&gt; do. But we do </FONT>

<BR><FONT SIZE=3D2>&gt; need to hear from other client implementors as =
to what they </FONT>

<BR><FONT SIZE=3D2>&gt; think is the </FONT>

<BR><FONT SIZE=3D2>&gt; right mode to use. I know other clients have a =
similar </FONT>

<BR><FONT SIZE=3D2>&gt; client-side view </FONT>

<BR><FONT SIZE=3D2>&gt; behaviour, and it might be worthwhile to why =
different modes </FONT>

<BR><FONT SIZE=3D2>&gt; were chosen.</FONT>

<BR><FONT SIZE=3D2>*** This is an area where there is no clear right or =
wrong answer. Arguments can be made for either behavior here.</FONT>
</P>

<P><FONT SIZE=3D2>Since you wanted input as to why different modes were =
chosen, here goes:</FONT>
</P>

<P><FONT SIZE=3D2>Microsoft clients choose the dynamic behavior since =
this tested better in our usability labs. Reason's why I think it tested =
better are:</FONT></P>

<P><FONT SIZE=3D2>1) Having consistent behavior is easier to explain to =
users. Users tend to like consistency. It is an easier to explain to a =
user that as messages change or arrive they will be added or dropped =
from the view accordingly, instead of going into the concepts of dynamic =
and semi-dynamic and stating that one set of rules apply to new messages =
and another to existing messages. If a user is a sophisticated enough =
user to set a filtered view, then the user tends to understand the =
concept of what a filter is and is not surprised that as they read =
messages, that those read messages drop from their unread filtered =
view.&nbsp; Thus since you are dealing with a relatively advanced user, =
the problem of a user being confused by &quot;messages disappearing from =
my view&quot; is relatively rare.</FONT></P>

<P><FONT SIZE=3D2>2) Filters are often used by users who have a lot of =
mail.&nbsp; When applying a filter such as &quot;show me only unread =
messages&quot;, they are great usability benefits by continually =
narrowing the number of messages that a user is dealing with as they =
move out of the filter criteria.</FONT></P>

<P><FONT SIZE=3D2>Say a user starts with 150 unread messages.&nbsp; As =
they continue to process and read their mail, the number of messages =
that they need to deal with diminished, making it much easier for the =
user to choose which of the remaining messages they want to read =
next.</FONT></P>

</BODY>
</HTML>
------_=_NextPart_001_01BFAF03.5FEE131E--

Date: Mon, 24 Apr 2000 20:59:01 +0000
From: Cyrus Daboo <[email-masked]>
To: Mike Gahrns <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views
Sender: [email-masked]

Hi Mike,
Sorry for the delay in getting back to you on this:

--On 04/07/00 10:57:46 -0700 Mike Gahrns <[email-masked]> 
wrote:

> I-D ACTION:draft-daboo-imapext-view-02.txt (fwd)At the Adelaide BOF
> several  of us brought up the fact that we were surprised that this
> latest draft  allowed for both semi-dynamic and dynamic views.   We had
> thought that at  the previous Washington D.C. BOF there was rough
> consensus that dynamic was  the way to go here.

No that was not the case: there wasn't consensus on the dynamic vs 
semi-dynamic view in Washington. It was decided to have a small 'design 
team' work on this issue and then present their suggestions/results to the 
list. For various reasons the 'design team' did not get going until about 
one month before Adelaide, and this left little time to really argue out 
this issue before the draft deadline. There was still debate between which 
of the two should be used, and whether there should only be one or both of 
them.

> Any client who wanted to expose a semi-dynamic view
> could do so easily by simply ignoring the dynamic updates from the 
server.

No - this is not simple! If messages have been removed from the server's 
view but the client wants to maintain them in its view, then there is a 
problem. The client can only refer to these messages by UID, as the VPN 
(view position number) is no longer applicable. One of the goals of VIEW is 
to remove the need for clients to maintain multiple mappings between 
different message identifiers, be they message numbers, UIDs or VPNs, to 
simplify sorting behaviour.

> I do not like the extra complexity that
> allowing both dynamic and  semi-dynamic views adds to the protocol.  And
> I know that for our particular  server implementation having both of
> these modes will add a large degree of  difficulty to our implementation.

I think there is certainly more consensus that there be only one mechanism, 
for reasons of simplicity. The question is which one.

>  It seems to me that this extra complexity is not worth the cost here, as
> the functionality could still be achieved relatively easily at the client
> without this extra complexity on the server.

The issue is whether it is easier for a client to implement semi-dynamic 
with a dynamic only server, or whether it is easier to do dynamic with a 
semi-dynamic only server. I would argue the later is the case. There is 
also the issue as to which is easier for a server, so there is a trade-off 
between client and server complexity that has to be addressed as well.

> I think one could also
> argue  that going with dynamic view only  would ultimately simplify
> client  development as well, since you no longer need to worry about what
> type of  server you are talking to.  At the Adelaide BOF, there was no
> representation  of people who wanted to see this "dual mode" of dynamic
> and semi-dynamic  views, so I said I would post to the list so that we
> could start a  discussion to resolve this issue.   Comments?

My personal feeling, based on experience with client-side views, is that 
the semi-dynamic mode is really what users expect clients to do. But we do 
need to hear from other client implementors as to what they think is the 
right mode to use. I know other clients have a similar client-side view 
behaviour, and it might be worthwhile to why different modes were chosen.

-- 
Cyrus

** Running Mulberry on LinuxPPC 2000 **

From: Mike Gahrns <[email-masked]>
To: Cyrus Daboo <[email-masked]>, IMAP Extensions WG <[email-masked]>
Subject: "dynamic" vs. "semi-dynamic and dynamic" views
Date: Fri, 7 Apr 2000 09:57:46 -0700 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFA0BA.B5760E7C
Content-Type: text/plain;
	charset="iso-8859-1"

I-D ACTION:draft-daboo-imapext-view-02.txt (fwd)At the Adelaide BOF several
of us brought up the fact that we were surprised that this latest draft
allowed for both semi-dynamic and dynamic views.   We had thought that at
the previous Washington D.C. BOF there was rough consensus that dynamic was
the way to go here.   Any client who wanted to expose a semi-dynamic view
could do so easily by simply ignoring the dynamic updates from the server.
I do not like the extra complexity that allowing both dynamic and
semi-dynamic views adds to the protocol.  And I know that for our particular
server implementation having both of these modes will add a large degree of
difficulty to our implementation.

 It seems to me that this extra complexity is not worth the cost here, as
the functionality could still be achieved relatively easily at the client
without this extra complexity on the server.  I think one could also argue
that going with dynamic view only  would ultimately simplify client
development as well, since you no longer need to worry about what type of
server you are talking to.  At the Adelaide BOF, there was no representation
of people who wanted to see this "dual mode" of dynamic and semi-dynamic
views, so I said I would post to the list so that we could start a
discussion to resolve this issue.   Comments?

------_=_NextPart_001_01BFA0BA.B5760E7C
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>&quot;dynamic&quot; vs. &quot;semi-dynamic and dynamic&quot; views</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I-D ACTION:draft-daboo-imapext-view-02.txt (fwd)At the Adelaide BOF several</FONT>
<BR><FONT SIZE=2>of us brought up the fact that we were surprised that this latest draft</FONT>
<BR><FONT SIZE=2>allowed for both semi-dynamic and dynamic views.&nbsp;&nbsp; We had thought that at</FONT>
<BR><FONT SIZE=2>the previous Washington D.C. BOF there was rough consensus that dynamic was</FONT>
<BR><FONT SIZE=2>the way to go here.&nbsp;&nbsp; Any client who wanted to expose a semi-dynamic view</FONT>
<BR><FONT SIZE=2>could do so easily by simply ignoring the dynamic updates from the server.</FONT>
<BR><FONT SIZE=2>I do not like the extra complexity that allowing both dynamic and</FONT>
<BR><FONT SIZE=2>semi-dynamic views adds to the protocol.&nbsp; And I know that for our particular</FONT>
<BR><FONT SIZE=2>server implementation having both of these modes will add a large degree of</FONT>
<BR><FONT SIZE=2>difficulty to our implementation.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;It seems to me that this extra complexity is not worth the cost here, as</FONT>
<BR><FONT SIZE=2>the functionality could still be achieved relatively easily at the client</FONT>
<BR><FONT SIZE=2>without this extra complexity on the server.&nbsp; I think one could also argue</FONT>
<BR><FONT SIZE=2>that going with dynamic view only&nbsp; would ultimately simplify client</FONT>
<BR><FONT SIZE=2>development as well, since you no longer need to worry about what type of</FONT>
<BR><FONT SIZE=2>server you are talking to.&nbsp; At the Adelaide BOF, there was no representation</FONT>
<BR><FONT SIZE=2>of people who wanted to see this &quot;dual mode&quot; of dynamic and semi-dynamic</FONT>
<BR><FONT SIZE=2>views, so I said I would post to the list so that we could start a</FONT>
<BR><FONT SIZE=2>discussion to resolve this issue.&nbsp;&nbsp; Comments?</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01BFA0BA.B5760E7C--