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. Similarly, -notification is also the responsibility of the application (but -probably via another service package.) Likewise, the package -provides no UI support.
+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. +Similarly, notification is also the responsibility of the +application (but probably via another service package.) Likewise, +the package provides no UI support.
Possible application domains include include calendaring, room reservation, scheduling, project management, and event registration.
@@ -36,32 +36,32 @@ meets the requirements for each of these areas in the following ways:-Events: The service creates a new subtype of acs_object: -acs_event. It creates an auxiliary table for mapping events to -parties. It provides an API for manipulating and querying events -and their associated time interval sets, activities, recurrences, -and parties.
+Events: The service creates a new subtype of +acs_object: acs_event. It creates an auxiliary table for mapping +events to parties. It provides an API for manipulating and querying +events and their associated time interval sets, activities, +recurrences, and parties.-Time Intervals: The service creates tables for storing -time intervals and sets of time intervals. It provides an API for -manipulating and querying time intervals and time interval +Time Intervals: The service creates tables for +storing time intervals and sets of time intervals. It provides an +API for manipulating and querying time intervals and time interval sets.
-Activities: The service creates a new subtype of -acs_object: acs_activity. It creates an auxiliary table for mapping -activities to objects. It provides an API for manipulating +Activities: The service creates a new subtype +of acs_object: acs_activity. It creates an auxiliary table for +mapping activities to objects. It provides an API for manipulating activities, their properties, and their associated objects.
-Recurrences: The service creates a table for storing -information on how an event recurs, including how the event recurs -and when it stops recurring. It provides an API for manipulating -recurrence information and recurring events. This includes a -function to insert event recurrences in such a way as to reasonably -limit the amount of information stored in the DB for a particular -event. This is done by only partially populating the recurrences -for certain events. The service also provides a view which -simplifies querying to find partially populated recurring events -that need recurrences added to the DB.
+Recurrences: The service creates a table for +storing information on how an event recurs, including how the event +recurs and when it stops recurring. It provides an API for +manipulating recurrence information and recurring events. This +includes a function to insert event recurrences in such a way as to +reasonably limit the amount of information stored in the DB for a +particular event. This is done by only partially populating the +recurrences for certain events. The service also provides a view +which simplifies querying to find partially populated recurring +events that need recurrences added to the DB.There are number of historical considerations surrounding the design of recurring events. Much of the current design can be @@ -90,8 +90,8 @@ 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 still -relevant, and then effectively constructing the item to be +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 single row, seems to require a significantly more complex design. @@ -100,9 +100,9 @@ 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 per -recurrence, plus all the added complexity of using the check repeat -proc.
+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 operates. Each class is represented as a recurring item and it is very common for each instance to have a different set of files @@ -120,20 +120,20 @@ 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 policy -to prevent problems, but it does provide mechanisms that a +
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 partially_populated_events view.
-insert_events takes either an event_id or a recurrence_id -and a cutoff date. It either uses the recurrence_id, or gets it -from the event_id, to retrieve the information needed to generate -the dates of the recurrences. When inserting a recurring event for -the first time, the application will need to call -insert_events with a reasonable populate_until date. For -calendar, for example, this could be sysdate + the lookahead -limit.
+insert_events takes either an event_id or a +recurrence_id and a cutoff date. It either uses the recurrence_id, +or gets it from the event_id, to retrieve the information needed to +generate the dates of the recurrences. When inserting a recurring +event for the first time, the application will need to call +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 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 @@ -152,22 +152,23 @@ inclusive (covering both Yahoo Calendar and Excite Planner) though 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, allows an -application to generate an arbitrary recurrence function. The -function must take a date and a number of intervals as arguments -and return a new date greater than the given date. The number of -intervals is guaranteed to be a positive integer.
+the original choices, but adds an additional choice, +'custom', which, when combined with the custom_func column, +allows an application to generate an arbitrary recurrence function. +The function must take a date and a number of intervals as +arguments and return a new date greater than the given date. The +number of intervals is guaranteed to be a positive integer.For the days_of_week column, the representation chosen, a space-delimited list of integers, has a number of advantages. First, it is easy and reasonably efficient to generate the set of -dates corresponding to the recurrences. insert_events takes -each number in the list in turn and adds it to the date of the -beginning of the week. Second, the Tcl and Oracle representations -are equivalent and the translations to and from UI are -straightforward. In particular, the set of checkboxes corresponding -to days of the week are converted directly into a Tcl list which -can be stored directly into the DB.
+dates corresponding to the recurrences. +insert_events takes each number in the list in +turn and adds it to the date of the beginning of the week. Second, +the Tcl and Oracle representations are equivalent and the +translations to and from UI are straightforward. In particular, the +set of checkboxes corresponding to days of the week are converted +directly into a Tcl list which can be stored directly into the +DB.Since this is a low level service package, there is no direct competition.
@@ -210,37 +211,38 @@ Tcl API, but if desired one could be added consisting primarily of wrappers around PL/SQL functions and procedures.This is the main abstraction in the package. acs_event -is a subtype of acs_object. In addition to the -acs_events table, there is an acs_event_party_map -table which maps between parties and events. The acs_event -package defines new, delete, various procedures -to set attributes and recurs_p indicating whether or not a -particular event recurs.
+This is the main abstraction in the package. +acs_event is a subtype of acs_object. In +addition to the acs_events table, there is an +acs_event_party_map table which maps between parties and +events. The acs_event package defines new, +delete, various procedures to set attributes and +recurs_p indicating whether or not a particular event +recurs.
Because time interval sets are so simple, there is no need to -make them a subtype of acs_object. Interval sets are +make them a subtype of acs_object. Interval sets are represented with one table to represent time intervals, and a second table which groups intervals into sets, with corresponding -PL/SQL packages defining new, delete, and +PL/SQL packages defining new, delete, and additional manipulation functions.
This is the secondary abstraction in the package. -acs_activity is a subtype of acs_object. In -addition to the acs_activities table, there is an -acs_activity_object_map table which maps between objects -and activities. The acs_activity package defines -new, delete, and various procedures to set +acs_activity is a subtype of acs_object. In +addition to the acs_activities table, there is an +acs_activity_object_map table which maps between objects +and activities. The acs_activity package defines +new, delete, and various procedures to set attributes and mappings.
Since recurrences are always associated with events, there seemed to be no need to make them objects. The information that determines how an event recurs is stored in the -event_recurrences table.
-The event_recurrence package defines new, -delete, and other procedures related to recurrences. The -key procedure is insert_events.
-A view, partially_populated_events, is created which +event_recurrences table.
+The event_recurrence package defines new, +delete, and other procedures related to recurrences. The +key procedure is insert_events.
+A view, partially_populated_events, is created which hides some of the details of retrieving recurrences that need to populated further.