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

RE: queries for unbounded recurring components



There is a slight problem with the following statement:

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

When it is Sunday in Houston, it could well, and for 6 hours, 5 for 1 week
in April,  will be, Monday in London.  

When the calendar user is traveling and is looking at a calendar that is
housed in TimeZone1, is currently in TimeZone2 and is looking at an event
for a time when they are in TimeZone3 the issue of who is expanding what
becomes non-trivial.  In general it should be done by the server which will
be the only system that will have all the information about the user on
which to base the expansion.


Chris.
?
?????????????????
Christopher A Lowde
Texaco
4800 Fournace Pl.
Bellaire, TX 77401-2324
Tel: +1(713)432-2901
Fax: +1(713)838-4529
mailto:lowdeca@texaco.com




 -----Original Message-----
From: 	John Stracke [mailto:francis@ecal.com] 
Sent:	Wednesday, October 27, 1999 11:25
To:	calsch WG
Subject:	Re: queries for unbounded recurring components

"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
> performance, both CPU and on the wire.

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."   |
|francis@ecal.com|--Russ Nelson                                |
\==============================================================/