Received: by ns.secondary.com (8.9.3/8.9.3) id QAA13874 for ietf-imapext-bks; Tue, 25 Apr 2000 16:28:18 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13870 for ; Tue, 25 Apr 2000 16:28:15 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id TAA07955; Tue, 25 Apr 2000 19:32:09 -0400 (EDT) Date: Tue, 25 Apr 2000 19:32:57 -0400 From: Cyrus Daboo To: Chris Newman , Mike Gahrns , IMAP Extensions WG Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views Message-ID: <2063793.3165679977@sardis.cyrusoft.com> In-Reply-To: <7569407.3165667344@dhcp-5.innosoft.com> X-Mailer: Mulberry/2.0.1b1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, April 25, 2000 4:02 PM -0700 Chris Newman 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 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13371 for ietf-imapext-bks; Tue, 25 Apr 2000 15:59:47 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13365 for ; Tue, 25 Apr 2000 15:59:45 -0700 (PDT) Received: from elvira.innosoft.com ([192.160.253.135]) by innosoft.com (PMDF V6.0-24 #9441) with ESMTPS id <01JONQ25CUAS8Y53XL@innosoft.com> for ietf-imapext@imc.org; Tue, 25 Apr 2000 16:03:22 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.innosoft.com by elvira.innosoft.com (PMDF V6.0-24 #43970) id <0FTL00901HCQ41@elvira.innosoft.com> for ietf-imapext@imc.org; Tue, 25 Apr 2000 16:02:51 -0700 (PDT) Received: from dhcp-5.innosoft.com (DHCP-5.INNOSOFT.COM [192.160.253.155]) by elvira.innosoft.com (PMDF V6.0-24 #43970) with ESMTPA id <0FTL0070EHCOV6@elvira.innosoft.com>; Tue, 25 Apr 2000 16:02:50 -0700 (PDT) Date: Tue, 25 Apr 2000 16:02:24 -0700 From: Chris Newman Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views In-reply-to: <9520000.956624341@socrates.cyrusoft.com> To: Cyrus Daboo , Mike Gahrns , IMAP Extensions WG Message-id: <7569407.3165667344@dhcp-5.innosoft.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Monday, April 24, 2000 20:59 +0000 Cyrus Daboo 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA12591 for ietf-imapext-bks; Tue, 25 Apr 2000 15:09:25 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA12587 for ; Tue, 25 Apr 2000 15:09:23 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Apr 2000 15:08:12 -0700 (Pacific Daylight Time) Received: from dino.platinum.corp.microsoft.com ([172.30.236.62]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2172.1); Tue, 25 Apr 2000 15:14:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4344.0 content-class: urn:content-classes:message Subject: RE: "dynamic" vs. "semi-dynamic and dynamic" views Date: Tue, 25 Apr 2000 15:12:41 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFAF03.5FEE131E" Message-ID: <9BE3A7FF0D67C341819FCA57736D5BC501102BB9@dino.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "dynamic" vs. "semi-dynamic and dynamic" views Thread-Index: Ab+u1udCuLawyAfdQdyeutyR4PsQIQAKb+vQ From: "Mike Gahrns" To: "IMAP Extensions WG" X-OriginalArrivalTime: 25 Apr 2000 22:14:10.0382 (UTC) FILETIME=[94AD6EE0:01BFAF03] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 RE: "dynamic" vs. "semi-dynamic and dynamic" = views

Cyrus writes:
> 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.
*** 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-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA09966 for ietf-imapext-bks; Tue, 25 Apr 2000 12:00:33 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09952 for ; Tue, 25 Apr 2000 12:00:10 -0700 (PDT) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA06989; Tue, 25 Apr 2000 12:58:45 -0400 (EDT) Date: Mon, 24 Apr 2000 20:59:01 +0000 From: Cyrus Daboo To: Mike Gahrns , IMAP Extensions WG Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views Message-ID: <9520000.956624341@socrates.cyrusoft.com> In-Reply-To: <003001bfa0b2$65f633c0$79fd3b9d@redmond.corp.microsoft.com> X-Mailer: Mulberry/2.0.0b8 (LinuxPPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mike, Sorry for the delay in getting back to you on this: --On 04/07/00 10:57:46 -0700 Mike Gahrns 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 ** Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA10132 for ietf-imapext-bks; Fri, 7 Apr 2000 10:58:54 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA10128 for ; Fri, 7 Apr 2000 10:58:53 -0700 (PDT) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Apr 2000 10:57:16 -0700 (Pacific Daylight Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <2PL5P8T7>; Fri, 7 Apr 2000 10:57:16 -0700 Message-ID: <003001bfa0b2$65f633c0$79fd3b9d@redmond.corp.microsoft.com> From: Mike Gahrns To: Cyrus Daboo , IMAP Extensions WG Subject: "dynamic" vs. "semi-dynamic and dynamic" views Date: Fri, 7 Apr 2000 09:57:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA0BA.B5760E7C" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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" "dynamic" vs. "semi-dynamic and dynamic" views

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-- Received: by ns.secondary.com (8.9.3/8.9.3) id QAA13874 for ietf-imapext-bks; Tue, 25 Apr 2000 16:28:18 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA13870 for ; Tue, 25 Apr 2000 16:28:15 -0700 (PDT) Received: from sardis.cyrusoft.com (sardis.cyrusoft.com [206.31.218.203]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id TAA07955; Tue, 25 Apr 2000 19:32:09 -0400 (EDT) Date: Tue, 25 Apr 2000 19:32:57 -0400 From: Cyrus Daboo To: Chris Newman , Mike Gahrns , IMAP Extensions WG Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views Message-ID: <2063793.3165679977@sardis.cyrusoft.com> In-Reply-To: <7569407.3165667344@dhcp-5.innosoft.com> X-Mailer: Mulberry/2.0.1b1 (MacOS) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Tuesday, April 25, 2000 4:02 PM -0700 Chris Newman 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 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13371 for ietf-imapext-bks; Tue, 25 Apr 2000 15:59:47 -0700 (PDT) Received: from THOR.INNOSOFT.COM (SYSTEM@THOR.INNOSOFT.COM [192.160.253.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13365 for ; Tue, 25 Apr 2000 15:59:45 -0700 (PDT) Received: from elvira.innosoft.com ([192.160.253.135]) by innosoft.com (PMDF V6.0-24 #9441) with ESMTPS id <01JONQ25CUAS8Y53XL@innosoft.com> for ietf-imapext@imc.org; Tue, 25 Apr 2000 16:03:22 -0700 (PDT) Received: from CONVERSION-DAEMON.elvira.innosoft.com by elvira.innosoft.com (PMDF V6.0-24 #43970) id <0FTL00901HCQ41@elvira.innosoft.com> for ietf-imapext@imc.org; Tue, 25 Apr 2000 16:02:51 -0700 (PDT) Received: from dhcp-5.innosoft.com (DHCP-5.INNOSOFT.COM [192.160.253.155]) by elvira.innosoft.com (PMDF V6.0-24 #43970) with ESMTPA id <0FTL0070EHCOV6@elvira.innosoft.com>; Tue, 25 Apr 2000 16:02:50 -0700 (PDT) Date: Tue, 25 Apr 2000 16:02:24 -0700 From: Chris Newman Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views In-reply-to: <9520000.956624341@socrates.cyrusoft.com> To: Cyrus Daboo , Mike Gahrns , IMAP Extensions WG Message-id: <7569407.3165667344@dhcp-5.innosoft.com> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0 (MacOS) Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --On Monday, April 24, 2000 20:59 +0000 Cyrus Daboo 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 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA12591 for ietf-imapext-bks; Tue, 25 Apr 2000 15:09:25 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id PAA12587 for ; Tue, 25 Apr 2000 15:09:23 -0700 (PDT) Received: from 172.30.236.11 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 25 Apr 2000 15:08:12 -0700 (Pacific Daylight Time) Received: from dino.platinum.corp.microsoft.com ([172.30.236.62]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2172.1); Tue, 25 Apr 2000 15:14:10 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4344.0 content-class: urn:content-classes:message Subject: RE: "dynamic" vs. "semi-dynamic and dynamic" views Date: Tue, 25 Apr 2000 15:12:41 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFAF03.5FEE131E" Message-ID: <9BE3A7FF0D67C341819FCA57736D5BC501102BB9@dino.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "dynamic" vs. "semi-dynamic and dynamic" views Thread-Index: Ab+u1udCuLawyAfdQdyeutyR4PsQIQAKb+vQ From: "Mike Gahrns" To: "IMAP Extensions WG" X-OriginalArrivalTime: 25 Apr 2000 22:14:10.0382 (UTC) FILETIME=[94AD6EE0:01BFAF03] Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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 RE: "dynamic" vs. "semi-dynamic and dynamic" = views

Cyrus writes:
> 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.
*** 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-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA09966 for ietf-imapext-bks; Tue, 25 Apr 2000 12:00:33 -0700 (PDT) Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA09952 for ; Tue, 25 Apr 2000 12:00:10 -0700 (PDT) Received: from socrates.cyrusoft.com (socrates.cyrusoft.com [206.31.218.216]) by darius.cyrusoft.com (8.9.3/8.9.3) with ESMTP id MAA06989; Tue, 25 Apr 2000 12:58:45 -0400 (EDT) Date: Mon, 24 Apr 2000 20:59:01 +0000 From: Cyrus Daboo To: Mike Gahrns , IMAP Extensions WG Subject: Re: "dynamic" vs. "semi-dynamic and dynamic" views Message-ID: <9520000.956624341@socrates.cyrusoft.com> In-Reply-To: <003001bfa0b2$65f633c0$79fd3b9d@redmond.corp.microsoft.com> X-Mailer: Mulberry/2.0.0b8 (LinuxPPC) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi Mike, Sorry for the delay in getting back to you on this: --On 04/07/00 10:57:46 -0700 Mike Gahrns 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 ** Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA10132 for ietf-imapext-bks; Fri, 7 Apr 2000 10:58:54 -0700 (PDT) Received: from dfssl.exchange.microsoft.com ([131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA10128 for ; Fri, 7 Apr 2000 10:58:53 -0700 (PDT) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 07 Apr 2000 10:57:16 -0700 (Pacific Daylight Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <2PL5P8T7>; Fri, 7 Apr 2000 10:57:16 -0700 Message-ID: <003001bfa0b2$65f633c0$79fd3b9d@redmond.corp.microsoft.com> From: Mike Gahrns To: Cyrus Daboo , IMAP Extensions WG Subject: "dynamic" vs. "semi-dynamic and dynamic" views Date: Fri, 7 Apr 2000 09:57:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFA0BA.B5760E7C" Sender: owner-ietf-imapext@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: 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" "dynamic" vs. "semi-dynamic and dynamic" views

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--