The package doesn't provide for any interpretation of +
The package doesn't provide for any interpretation of events, leaving that up to the applications that use the service. In particular, the package assumes that permissioning, and the related concept of approval, will be handled by the application. @@ -90,7 +90,7 @@ advantage of the index on the start_date column to optimize the query. With the stored proc, it would be necessary to iterate over each day (up to 42 in the month view), calling the check repeat -proc for each base repeating item who's repeat_until date was +proc for each base repeating item who's repeat_until date was still relevant, and then effectively constructing the item to be displayed.
Another reason is that the first approach, to insert only a @@ -100,7 +100,7 @@ Now you need to maintain a separate table of exceptions and it becomes necessary to check through the exceptions table every time the check repeat proc is called. It the worst case, every -recurrence is an exception, so you're essentially back to 1 row +recurrence is an exception, so you're essentially back to 1 row per recurrence, plus all the added complexity of using the check repeat proc.
This is not an unreasonable possibility and is in fact how Sloan @@ -120,7 +120,7 @@ systems seem to have arbitrary, implementation driven limits. Yahoo and Excite have arbitrary limits between about 1970 and 2030. Palm seems to have no lower limit, but an upper limit of 2031.
-The 4.0 ACS Events service doesn't enforce a particular +
The 4.0 ACS Events service doesn't enforce a particular policy to prevent problems, but it does provide mechanisms that a well-designed application can use. The keys are the event_recurrence.insert_events procedure and the @@ -134,7 +134,7 @@ insert_events with a reasonable populate_until date. For calendar, for example, this could be sysdate + the lookahead limit.
-It is the application's responsibility to determine if +
It is the application's responsibility to determine if additional events need to be inserted into the DB to support the date being used in a query to view events. The application can do this by querying on partially_populated_events, using the date in @@ -150,7 +150,7 @@ event_recurrence.interval_type. The original choice for the 3.4 calendar was based on the Palm DateBook which seemed fairly inclusive (covering both Yahoo Calendar and Excite Planner) though -it didn't capture some of the more esoteric cases covered by +it didn't capture some of the more esoteric cases covered by Outlook or (particuarly) Lotus Notes. The Events service maintains the original choices, but adds an additional choice, 'custom', which, when combined with the custom_func column, @@ -254,7 +254,7 @@ Remember that the correctness, completeness, and stability of the API and interface are what experienced members of our audience are looking for. This is a cultural shift for us at aD (as of mid-year 2000), in -that we've previously always looked at the data models as key, and +that we've previously always looked at the data models as key, and seldom spent much effort on the API (e.g. putting raw SQL in pages to handle transactions, instead of encapsulating them via procedures). Experience has taught us that we need to focus on the API for