[Dev] Re: Recurrance discussion

[Phillip J. Eby]

At 09:30 AM 5/11/2005 -0700, Katie Capps Parlante wrote:
>Bryan has a good list below, of requirements for occurrence objects.
>
>Perhaps a next step is to agree on the contract (including API) that the 
>view will expect from the model. The views that are important for 0.6 are 
>the CPIA views (Detail View, Summary Table View, Calendar View). The model 
>is the content model and modelling layer below, which includes occurrence 
>objects as well as the ways that we find/create occurrence objects -- 
>queries, item collections, etc.
>
>Once we agree on the contract, perhaps we can think of the 
>transient/persistent issue as an implementation issue, where we might make 
>one choice for 0.6 and another choice in the future. Of course, we need to 
>be thoughtful about implementation issues (as you all have been) as we 
>arrive at the contract.
>
>These requirements seem not especially controversial:
>+ Occurrence items need to show up in item collections (and as results of 
>queries).
>+ Occurrence items need to support Item's introspection apis 
>(getAttributeAspect, etc. -- perhaps good to make an explicit list here)
>
>We certainly need to be able to handle notifications for changed 
>occurrence items -- that is a requirement. If I understand correctly, that 
>currently implies this requirement:
>+ Occurrence objects should respond to repository monitors

(Note: Neither of the proposals below is complete in itself; I'm dealing 
here only with the issue of generating occurrence objects, *not* with the 
masters vs. occurrences debate or other information sharing and duplication 
parts.)

Strawman proposal 1: implement occurrences as real items, created when the 
rule is modified.  Require users to *always* include an explicit end date; 
i.e., no unbounded recurrences.

Pros: extremely simple to implement, with clear and explicit behavior that 
allows the user to trade off performance and convenience.  If the user 
wants 100 years worth of birthdays, more power to 'em.  If they want 100 
years worth of daily exercise classes, they'll have to wait a while for 
events to be generated and modified, and this should probably be an 
acceptable tradeoff for 0.6.

Cons: Slow when creating or modifying large numbers of recurrences, but 
this will get faster "for free" as the repository gets faster.  The more 
important "con" is that a user might set up five years of daily exercise 
and then be puzzled five years later when the occurrences stop 
appearing.  While it'd be trivial to click on the last occurrence and 
change the end date, it's possible you might not think of doing it.  And 
for more infrequent things like birthdays and the like, the lack of 
repetition past a certain point might be non-obvious and therefore more 
problematic.


Strawman proposal 2: The same as proposal 1, but allow users to not set an 
end date.  If no end date is supplied, generate a *fixed* number of 
repetitions using a heuristic based on the frequency of occurrence.  For 
example, for annual occurrences you could schedule 10 or 12 years in 
advance, while we might limit daily occurrences to a year's worth.  This 
caps the cost of generating occurrences, but increases complexity by 
requiring the heuristic logic, and by requiring an alarm or something of 
that sort associated with each recurrence to automatically add one *more* 
occurrence each time one is consumed, thereby keeping the "sliding window" 
always the same size.

Proposal 1 could be implemented for 0.6, with the more sophisticated 
version in proposal 2 being added in a later version as an additional feature.