[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Use of LIST-EXTENDED


We have in the past had several documents depending on LIST- EXTENDED. Since this document has taken so long, various authors have reduced those dependencies and we now have no more active drafts that depend on LIST-EXTENDED. This URL will show the drafts that depend and note they're all expired:

http://rtg.ietf.org/~fenner/ietf/deps/index.cgi?dep=list-extensions

Alexey, Michael, it would be good to get a sense of what you'd be doing with LIST-EXTENDED if it did go forward -- reissue those drafts? Or is it no longer needed?

Anybody else, would you use LIST-EXTENDED if it went forward in its *current* form? Or only if it did hypothetical extensions such as the one outlined by Dave?

Lisa


On Jan 26, 2006, at 7:25 AM, Dave Cridland wrote:


Let's define a hypothetical extension to LIST-EXTENDED:

It has a return option RECENT, which returns the recent count of a mailbox.

It also has a "base" selection option RECENT, which restricts the selection to mailboxes which have a non-zero recent message count. Being a base option, it means that this may be used with RECURSIVEMATCH. We'll make it imply the RECENT return option, as is traditional.

Now... What I'd like to do with this extension is show my GUI tree control of mailboxes which are subscribed, with little expander buttons for those that have subscribed children, and also highlight those mailboxes which have recent messages - or subscribed children which have recent messages.

In other words, assuming:

A01 LIST (SUBSCRIBED) "" "*" RETURN (RECENT)
* LIST (\Subscribed \UnMarked) "/" Foo
* LIST (\Subscribed \Marked) "/" Foo/Bar/Baz ((RECENT "24"))
* LIST (\Subscribed \Marked) "/" Zab ((RECENT "42"))
* LIST (\Subscribed \UnMarked) "/" Boring
A01 OK

Then I want to show Foo, Zab, and Boring. Foo and Zab will both be highlighted, Boring will not be. Zab will have a recent count displayed next to it.

In order to do this, I need to:

B01 LIST (SUBSCRIBED RECURSIVEMATCH) "" "%"
B02 LIST (SUBSCRIBED RECENT RECURSIVEMATCH) "" "%"

B01 here gets the mailbox listing and the tree "expander" information. B02 gets the highlighting information. The server has to recusrively search twice.

What I'd really like to do, though, is the imaginary syntax:

C01 LIST (SUBSCRIBED RECURSIVEMATCH (SUBSCRIBED) RECURSIVEMATCH (SUBSCRIBED RECENT)) "" "%" RETURN (RECENT)

In other words, "Tell me all the subscribed mailboxes at the top level, and also include CHILDINFO blocks for SUBSCRIBED and SUBSCRIBED+RECENT".

I can think of more use-cases for this than for multiple mailbox patterns, incidentally.

From the server's perspective, it now has to perform the recursive mailbox search only once through, rather than twice, which seems more efficient.

Is this worth considering at this late stage?

Dave.
--
          You see things; and you say "Why?"
  But I dream things that never were; and I say "Why not?"
   - George Bernard Shaw