Our primary focus was the content model for recurrence: should recurring events manifest themselves as a single item, or as a single recurrence item with persistant instances created on demand. (Based on conversations with Andi, Jeffery had discarded the idea that we might use somehow-unpersisted instance items.)
The single-item model would require that anyone else who needed to interact with a recurring event also be given a parameter that specified which instance was to be displayed. This seemed undesirable because of its widespread effect: an item doesn't have enough context on its own to be displayable, so everything that needs to interact with that item needs a contextual parameter, to know which attributes are time sensitive and to use that contextual parameter to display the item.
We then talked about the other model, where instances of recurring events would be items in their own right, with a reference back to the recurrence object. This is advantageous because items don't require extra context, and only those attributes related to recurrence need to consider the recurrence object. The disadvantage here is that we'd need a scheme to manage the instances, creating them at an appropriate time so that all needed instances actually exist.
We talked back and forth about this for a bit; we concluded by agreeing that Jeffery would go back and consider the ramifications of the persistent-instances model, since it seems to reduce the impact on the rest of the app.
- Ted and Andi, please chime in if you've got thoughts about how this might be affected by the new collection/query stuff and the repository.
- It'd be useful to know how iCal thinks about this internally, since we're modeling a lot of our behavior on it - if anyone has contacts at Apple who'd share this with us, please pipe up.
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
