headers
Cyrus Daboo | 3 Aug 1999 16:50

[VIEW] Dynamic vs static

Hi folks,
At the Oslo meeting we had discussions about whether the VIEW extenions
should be dynamic or static with respect to message changing position in a
view. This issue was not fully resolved and so I'm kicking off some list
discussion about it.

Right now the VIEW extension requires dynamic updates (via responses) from
the server for:

a) new messages arriving in the mailbox
b) messages being expunged from the mailbox
c) messages moving into or out of a view due to a change in some message
state (right now only flags, but this may include annotations once that's
available)

Of these I think (a) and (b) MUST be present. We were all agreed in Oslo
that (a) matches user expectations - i.e. the arrival of any new message
that matches the current view criteria MUST result in that message
appearing in the client's view.

(b) is merely an extenion of the current expunge mechanism where messages
have to be removed from the clients cache when an expunge occurs.

(c) is really the issue of this debate. Should changes to a message's state
be notified to the client via untagged responses?

One argument against a dynamic view is to consider the case of a view set
to display only unseen messages. As soon as a user tries to read such a
message the \Seen flag is implicitly set (of course the client could use
the .PEEK FETCH variant to stop this). At that point in a dynamic view, the
(Continue reading)

Permalink | Reply | 11 comments |
headers
Cyrus Daboo | 3 Aug 1999 17:07

[VIEW] Multiple views

The issue of whether the VIEW extension should support multiple views was
raised in Oslo. Here are Steve's minutes on the subject for reference:

> ** Support for multiple VIEWS
> - very expensive for the server implementors
> - will clients actually use it?
>   - there are examples of how a client might use it.
>   - some vendors clearly expressed a desire to have it.
> - there are other workarounds (multiple connections, refining criteria
>   on reissued VIEW)
> - punt issue to list

I think it was clear that most server vendors felt this was adding too much
complexity to VIEW from the outset and would provide too much of a hurdle
for the adoption of the VIEW extension. Is this really how people feel
about this now?

One solution is to design VIEW now as a single VIEW mechanism but to allow
a VIEW2 extension to extend it for multiple views once VIEW has proven
itself to be useful and is widely adopted. If we were to do this it might
be sensible to take this into account when designing VIEW. What I think we
could do is make the definition of the view position more than just the
hierarchical number currently proposed in the extension. If instead we
allowed it to be single or multi-valued then we could add multiple view
very easily in the future.

For example, with multiple views we could say the view position specifier
has two levels of hierarchy - the first is the multiple view number, the
second the position of the message in the view. e.g. view position of 2.3
refers to the third message in view order in the second view. By also
(Continue reading)

Permalink | Reply | 501 comments |
headers
Cyrus Daboo | 3 Aug 1999 17:14

[ANNOTATE] Mailbox and server level annotations

The current annotation extension being discussed is for message annotations
only (i.e. each message could have its own set of annotations).

Its also potentially useful to allow mailbox annotations and indeed server
annotations.

For example, mailbox annotations could include annotations describing what
particular sort order a user likes to view this mailbox in, or the window
position and size for displaying a particular mailbox, or a detailed
description of the mailbox contents etc.

Server annotations might include a URL to a webpage for managing accounts
on the server or for doing password changing, a way to map user ids into
user names for handling access control lists, a description of who to
contact when things go wrong on the server etc

Would people find these useful? If they are worth considering as an
extension, they should probably be separate from message annotations, and
indeed separate from each other (i.e. we end up with three annotation
documents).

Any comments?

--
Cyrus
Permalink | Reply | 0 comments |
headers
Barry Leiba | 3 Aug 1999 21:36
Picon
Favicon

Re: [VIEW] Dynamic vs static

Cyrus Daboo wrote:
> (c) is really the issue of this debate. Should changes to a message's state
> be notified to the client via untagged responses?
> 
> One argument against a dynamic view is to consider the case of a view set
> to display only unseen messages. As soon as a user tries to read such a
...
> suddenly the message the user is trying to read is now outside of the
> client's view! I think this is probably counter to user expectations.

One thing to remember is that this has nothing to do with *user* 
expectations; it's purely a matter for the client to deal with.  The
original design of the "view" concept as an extension to "select" had
it that messages outside the view weren't available to the client.
That's no longer the case.  Therefore, a client could easily retrieve 
the UIDs of the messages it presents to the user, and needn't remove
those messages from the user's view when they're removed from the 
client's view.

Another way of looking at it is that the client uses the view sequence 
numbers to build the UI, but thereafter refers to the messages by UID.

I think the only reasonable and consistent thing to do, given the current 
design, is to make the view fully dynamic.

Barry Leiba, Internet Messaging Technology  (leiba <at> watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
Permalink | Reply | 6 comments |
headers
Cyrus Daboo | 3 Aug 1999 22:30

Re: [VIEW] Dynamic vs static

--On Tuesday, August 03, 1999, 3:36 PM -0400 Barry Leiba
<leiba <at> watson.ibm.com> wrote:

> One thing to remember is that this has nothing to do with *user* 
> expectations; it's purely a matter for the client to deal with.  The
> original design of the "view" concept as an extension to "select" had
> it that messages outside the view weren't available to the client.
> That's no longer the case.  Therefore, a client could easily retrieve 
> the UIDs of the messages it presents to the user, and needn't remove
> those messages from the user's view when they're removed from the 
> client's view.
> 
> Another way of looking at it is that the client uses the view sequence 
> numbers to build the UI, but thereafter refers to the messages by UID.

No - this is counter to one of the main purposes of VIEW. What you are
suggesting requires the client to cache the entire view position<->UID
mappings for ALL messages in the view. But the one important point of VIEW
is that clients only need to download information for those messages it
needs to show to the user (i.e. virtual scrollbar). If you force the client
to maintain its own map then its really no different from what Mark
originally proposed with SORT.

Basically a client should be able to solely rely on view positions as
opposed to sequence numbers or UIDs if needs be.

--
Cyrus
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barry Leiba | 3 Aug 1999 23:05
Picon
Favicon

Re: [VIEW] Dynamic vs static

> No - this is counter to one of the main purposes of VIEW. What you are
> suggesting requires the client to cache the entire view position<->UID
> mappings for ALL messages in the view.

No, not at all.  Only the messages it's shown the user.  If the user 
hasn't seen the message, then the fact that it's disappeared from the
view is irrelevant.  Once the user has seen the message (it's come up
in the virtual window), then the client has presumably picked up the 
ENVELOPE and FLAGS information, for instance (in order to display it 
in the UI), and, so, can also have picked up the UID at the same time.

Barry Leiba, Internet Messaging Technology  (leiba <at> watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
Permalink | Reply | 4 comments |
headers
Mark Crispin | 4 Aug 1999 02:14

re: [VIEW] Multiple views

On Tue, 03 Aug 1999 11:07:06 -0400, Cyrus Daboo wrote:
> I think it was clear that most server vendors felt this was adding too much
> complexity to VIEW from the outset and would provide too much of a hurdle
> for the adoption of the VIEW extension. Is this really how people feel
> about this now?

If the VIEW extension ends up requiring support for multiple views, I probably
won't implement it.

> One solution is to design VIEW now as a single VIEW mechanism but to allow
> a VIEW2 extension to extend it for multiple views once VIEW has proven
> itself to be useful and is widely adopted. If we were to do this it might
> be sensible to take this into account when designing VIEW.

I agree that VIEW should claim to be a proper subset of all IMAP capabilities
with begin with "VIEW", so as to provide extensibility.

> What I think we
> could do is make the definition of the view position more than just the
> hierarchical number currently proposed in the extension. If instead we
> allowed it to be single or multi-valued then we could add multiple view
> very easily in the future.

Ugh!  Think about what would happen if people want multiple *nested* views.
Please, let's not go here.

>         S: * 173 VIEW 5274234 (1.14 2.3)
>         A new message arrived and appeared at position 14 in view 1
>         and at position 3 in view 2.
> Note also that in the case of view operating with the THREAD extension, its
(Continue reading)

Permalink | Reply | 501 comments |
headers
Mark Crispin | 4 Aug 1999 01:45

re: [VIEW] Dynamic vs static

One way of looking at this is that "what IMAP does is not necessarily what the
client will show".  We should focus on what is best for client implementations
(because clients are what will benefit from it) and what is feasible for
server implementations (because if it isn't feasible then servers won't
implement it).

I think that I reject any idea to be "smart", e.g. making a special exception
for the \Seen or \Recent flags for "new" messages.

I think that our choices are:

1) fully-static.  Once a view is set, it's immutable.  I guess that this means
   that if a message in the view is expunged, the view gets a hole.

2) semi-static.  Once a message is entered into the view, it stays there even
   if its state changes in a way that would cause it to leave the view.
   However, expunged messages are removed from the view (so you can do math on
   view ids the way you can on sequences), and new messages are incorporated
   into the view as appropriate.

3) dynamic.  Messages are added to the view via new messages or if the state
   of a non-viewed message changes.  Messages are removed from the view via
   expunge or if the state of a viewed message changes.

I think that (1) is probably a non-starter for client implementors.  It would
be the easiest to implement for server implementors, since it doesn't require
us to remember the VIEW SET (as opposed to the map created by it).  The
problem with VIEW UPDATE is that it combines the worst of both worlds -- it
requires the client to issue a command to fix the view, and it requires the
server to remember the VIEW SET.  Let's reject VIEW UPDATE for (1), say "with
(Continue reading)

Permalink | Reply | 3 comments |
headers
Cyrus Daboo | 4 Aug 1999 18:40

re: [VIEW] Dynamic vs static

--On Tuesday, August 03, 1999, 4:45 PM -0700 Mark Crispin
<MRC <at> CAC.Washington.EDU> wrote:

> One way of looking at this is that "what IMAP does is not necessarily
> what the client will show".  We should focus on what is best for client
> implementations (because clients are what will benefit from it) and what
> is feasible for server implementations (because if it isn't feasible then
> servers won't implement it).

Well I would like to throw something else into this equation - namely
'users'. Its all well and good to have this functionality available on
client and server but if its too difficult for the user to use, or doesn't
do what they really want it to, then its not going to be of much use.

Its already the case that a number of client vendors have a VIEW type
mechanism built into their clients, using client-based searching etc to
determine the view. I know from our own experience (about a year's worth)
that users want to have any new messages that arrive with matching view
criteria immediately displayed to them. In other words new message arrival
MUST result in dynamic VIEW responses.

Also, having looked back at user discussions, its clear that they do NOT
want a fully dynamic view at least in the sense that messages dissappear
from the view if they no longer match because of a flag change.

In other words option (2) as described in Mark's original post matches
(our) users' expectations of how view should work.

I think we should hear from otehr client vendors with a similar client-side
mechanism to see what their usability studies suggest in this area.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Cyrus Daboo | 4 Aug 1999 18:50

Re: [VIEW] Dynamic vs static

--On Tuesday, August 03, 1999, 5:05 PM -0400 Barry Leiba
<leiba <at> watson.ibm.com> wrote:

> No, not at all.  Only the messages it's shown the user.  If the user 
> hasn't seen the message, then the fact that it's disappeared from the
> view is irrelevant.  Once the user has seen the message (it's come up
> in the virtual window), then the client has presumably picked up the 
> ENVELOPE and FLAGS information, for instance (in order to display it 
> in the UI), and, so, can also have picked up the UID at the same time.

Right, but from then on the client has to go through a complex procedure
for figuring out which messages are in its display list and are part of the
server view and which are not part of the server view. So if a user selects
all the messages and then does a delete, the client ends up having to issue
two commands to delete the message: 'VIEW STORE' for messages in the server
view, and 'UID STORE' for messages outside the server view. It has to do
the same sort of thing if the user just wants to search the message within
the client's current view. There's no reason why a client can't do this,
but I don't think we should force this complex behaviour by requiring VIEW
to be fully dynamic, if most clients really want the static form of view.

Remember, its easy for a client to take the static form of VIEW and
effectively emulate a dynamic form by simply issuing a 'VIEW UPDATE'
command everytime there's an unsolicted response from the server that might
result in a change to the view. Its much harder to emulate the static mode
when the server only supports the dynamic mode.

There is another option that I didn't mention in my first port on this, and
that is the possibility of allowing both dynamic and static views but have
the client decide when the VIEW is set which it wants.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane