Subject: RE: queries for unbounded recurring components

From: "Lisa Lippert \(Dusseault\) \(Platinum\)" <[email-masked]>
Date: Thu, 21 Oct 1999 08:40:56 -0700

Generally I agree with John's principle to push things to the edges, but
I'm not so sure on this one.  The problem is that to do a simple query
such as "what appointments do I have today?", the client has to either
rely on the server to do expansion, OR the client has to download all
appointments today, plus all appointments that recur.  That becomes
expensive once again in terms of bandwidth. And it may in fact be just
about as easy for the server to do the recurrence expansion than to
stream all those recurring items.

It may be reasonable to limit the amount of expansion the server has to
do, though.  It could be interesting to allow the client to request
recurrance expansion for a range of dates, and for the server to be able
to respond "no".  (Then the client just has to download the recurring
items).  That flexibility on the server allows it to tune for the best
performance, both CPU and on the wire.

Lisa

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On
Behalf Of John Stracke
Sent: Wednesday, October 20, 1999 9:09 AM
To: calsch WG
Subject: Re: queries for unbounded recurring components

Steve Mansour wrote:

> Hmmm... I think it's more involved than that.  Are you
> suggesting that all clients/requesters should know how to
> expand the RRULE?  A light-weight client app may want all the
> instances of a recurring event.

Yes, but we have to think about bandwidth issues--especially
since one of the important places for thin clients is in non-PC
devices in the home, where you probably have 56k or less.

I would prefer to see a protocol where the server is never
required to do the expansion itself.  CPU time is so much cheaper
than bandwidth that it's unreasonable for the clients not to take
on the load.  (For that matter, why should the overworked server
CPU take on that work for its thousands of clients? Push the hard
parts to the edges; that's what makes the Internet run.)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Help stamp out vi in our lifetime!           |
[email-masked]|                                             |
\==============================================================/

---

From: John Stracke <[email-masked]>
Date: Wed, 27 Oct 1999 12:25:29 -0400

"Lisa Lippert (Dusseault) (Platinum)" wrote:

> Generally I agree with John's principle to push things to the
> edges, but I'm not so sure on this one.  The problem is that to
> do a simple query such as "what appointments do I have today?",
> the client has to either rely on the server to do expansion, OR
> the client has to download all appointments today, plus all
> appointments that recur.

Not necessarily; the server may not have to expand the recurring
event in order to find out whether it occurs on a given day.  For
example, if we have:

DTSTART;TZID=US-Eastern:19970105T083000
RECUR:FREQ=WEEKLY

Then the server says, "OK, 19970105 is a Sunday; is the day being
asked about a Sunday?".

> It may be reasonable to limit the amount of expansion the
> server has to do, though.  It could be interesting to allow the
> client to request recurrance expansion for a range of dates,
> and for the server to be able to respond "no".  (Then the
> client just has to download the recurring items).  That
> flexibility on the server allows it to tune for the best

Yeah, but every extra bit of flexibility in the protocol makes
for more cases to test for interop--and it's a combinatorial
problem, not linear.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"Time is money, and price is information."   |
[email-masked]|--Russ Nelson                                |
\==============================================================/

---

From: Doug Royer <[email-masked]>
Date: Wed, 27 Oct 1999 10:43:54 -0700

> Then the server says, "OK, 19970105 is a Sunday; is the day being

It still breaks one of the CAP goals. To support what
we called thin clients.

---

From: John Stracke <[email-masked]>
Date: Sat, 30 Oct 1999 10:48:41 -0400

Doug Royer wrote:

> > event in order to find out whether it occurs on a given day. [...]
>

Yes, but there are dimensions of thinness; many thin clients will be
more concerned about bandwidth than about processor power.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |I will not buy this .signature, it is scratched.|
[email-masked]|                                                |
\=================================================================/

---

From: Doug Royer <[email-masked]>
Date: Sun, 31 Oct 1999 10:44:44 -0800

> more concerned about bandwidth than about processor power.

Which is why it is important to do both?