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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
