Subject: [lemonade] Going way out on a limb on search-within

From: Eric Burger <[email-masked]>
Date: Mon, 14 May 2007 14:44:15 -0400

OK, so the #1 complaint has been that on the one hand, we do not want to
allow clients to specify an arbitrarily small search interval, as that can
lock-up the server.  On the other hand, if the client picks an interval that
is too small, the server mysteriously happens to send updates at a longer
interval.

Base Proposal:
In the capabilities exchange, instead of saying "WITHIN", the server
responds with "WITHIN=min", where min is the minimum number of seconds the
server is willing to offer updates.

With that information, I have two proposals for how the protocol can work.

Proposal #1:
If the client requests an OLDER or YOUNGER interval that is not evenly
divided by the WITHIN=min specification, the server returns NO.  The client
knows what the server can do, so if the client asks for something else,
shame on it.

Proposal #2:
If the client requests an OLDER or YOUNGER interval that is not evenly
divided by the WITHIN=min specification, the server processes the request as
if the client requested the closest interval, rounding up if the interval
would fall exactly in the mid-range of the interval.  If the result is zero,
then we round down for YOUNGER and up for OLDER, to have the more
restrictive result set.

The benefit of proposal #1 is that it is exact.  There is no ambiguity.  The
client has sufficient information to construct a user interface that
presents the possible options.  For example, if the server responds
WITHIN=2, the client knows to only offer even intervals.  Likewise, if the
server responds WITHIN=30, and the user asks for OLDER 25, the client can
tell the user that 25 equals 30, and the client can make the request for 30.

The benefit of proposal #2 is that it is way easier on clients.  In proposal
#1, the user interface has to be dynamic.  Either the user interface only
offers intervals that are multiples of WITHIN=min or the user interface has
to check the user's request is a multiple of WITHIN=min.  In proposal #2,
one can construct a client that does not really understand the interval, and
the server will do something close to what the user requested.

My personal preference is for #1, but I do not build clients.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Dave Cridland <[email-masked]>
Date: Tue, 15 May 2007 16:14:41 +0100

On Mon May 14 19:44:15 2007, Eric Burger wrote:
> lock-up the server.

No, it can't. :-)

The size of the value given as argument to OLDER or YOUNGER has no 
effect whatsoever on server load. What affects it is how often the 
server has to re-evaluate it.

Rather than mess about with granularity of the OLDER/YOUNGER, why not 
replace paragraph 2/3 of section 2 with:

In those cases where the search criteria are used to provide 
dynamically updated results, the strict definition of YOUNGER and 
OLDER above means that the target date and time requires 
recalculating every second, leading to new comparisons every second 
in turn. Servers may be unable, or unwilling, to do this, and in 
these cases, the target date and time MAY be recalculated less 
frequently. Servers MUST recalculate the target date and time at 
least once every X seconds, or as frequently as required by the 
dynamic search mechanism.

For example, if a SEARCH command with YOUNGER 1 is executed at any 
time against a mailbox containing a message which arrived one second 
ago, that message will match. However, if used with a dynamic search, 
it may be up to X seconds until that message is removed from the 
result set.

You get to pick X, I don't care too much.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 May 2007 17:21:14 +0100

Dave Cridland wrote:

> effect whatsoever on server load.

Agreed. It is not different from (e.g.) SINCE search criterion.

> What affects it is how often the server has to re-evaluate it.
>
> OLDER above means that the target date and time requires recalculating 
> every second, leading to new comparisons every second in turn. Servers 
> may be unable, or unwilling, to do this, and in these cases, the 
> target date and time MAY be recalculated less frequently. Servers MUST 
> recalculate the target date and time at least once every X seconds, or 
> as frequently as required by the dynamic search mechanism.
>

I like that.

> You get to pick X, I don't care too much.

I suggest we stick with 1 hour as agreed before.