RE: queries for unbounded recurring components

[Bruce_Kahn@xxxxxxxx]

Lisa wrote:
>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.

Before I espouse my KISS mantra again, Id like to note that one monkey wrench that has not yet been considered in this discussion is the return of signed and/or encrypted data.  So far we have agreed that we have some design issues dealing with signed/encrypted data but we have not directly addressed 'em.  Not sure if that is because we expect our borrowed security types to do this for us or if we are being a collective ostrich...

Back to the wrench: If the data is signed then this could be blown if the CS returns only partial data (either because the client asked for only a partial set or becuase the CS restricted it for some reason like restricted expansion).  Also, since recurrance instances may not be explicitly signed (ie: "RRULE:FREQ=WEEKLY;BYDAY=MO") then extracting the full snapshot of the instance for 01-Nov-1999 would result in either incorrect or missing signatures.  This could be an argument for where signatures and encryption may not be usable in our C&S world as we currently expect it to be...

If the data is encrypted, then unless the CS has the key to crack open the data and return the expected chunks we have to deal with another serious architecture issue.  The same issues applies to the extracting a single instance from an encrypted chunk and then reencrypting it for the CU; just what do we expect the CS to realistically do?

Im tapped out now but I promise to get some free cycles before DC to devote to this.  Whatever solution we collectively come to, I hope it follows the KISS principle so that we dont build something big, obtuse and very unwieldy that we have to code up and live with for several years!  The simplest designs usually last better than very complex ones (very paraphrased form Sir Arthur Conan Doyle).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@iris.com
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...