Jeffrey updated the recurrence spec (rev 1.6 now), but I've still got many of the same questions.
(Note that I haven't thought all these things through, and I'm bringing them up only to make sure we've considered all the angles as we close on a design. If the consensus is to forge ahead and handle problems on the way, that's fine.)
The question I asked in my ealier message below (single-item model vs recurrence instances in their own right) seems to be resolved in favor of multiple objects; the spec proposes two alternatives how the recurrence objects exist: "transient" or "persistent". Though it asks some hard questions (eg, in the "persistent" model, who manages the persistant instances?), it doesn't propose answers, or lean one way or the other... so I will: ;-)
I think that transient items will cause more problems than they solve: every aspect of behavior of Chandler Items, at every level, will need to be examined and covered before we'll know whether this "pretending" is successful. Scary cases include
- whether they can belong to collections
- whether their schema information can be queried
- when the items are stamped (either before or after recurrence is added), what other mixin classes need to know about them
- can I use a repository monitor to watch for changes on one of these items?
- where do reminders live? what happens when the user dismisses or snoozes one?
Proxying has issues in general, too: proxying will need to proxy attributes, properties, and method calls to the original item. How will the proxy mechanism know whether an operation changes the original item (thus requiring the "do you want to change the original event, all occurrences, or all after this one?" alert)?
I'm also concerned about whether the query code should be responsible for creating these instances - that seems too low-level. It seems like it'd be simpler to run a task whenever Chandler starts, that would make sure we've got a year's worth of instances of all recurring events, and deletes old ones as appropriate. (This also seems like a more localized implementation: if it turns out to be unsuitable, we just throw away this code. If we have to change many levels of the system to make "pretend" items work -- the query system, the repository, whatever knowledge has to be in other mixins' code -- it'll be harder to back out.)
Also, did anyone try to find out what iCal does? (Katie, weren't you going to contact someone?)
...Bryan
Bryan Stearns wrote:
Jeffery, Alecf, and I had a discussion this morning about calendar recurrence. We didn't come to any firm conclusions, but I wanted to let others know the things we discussed, and solicit feedback. (If I've gotten any of the details wrong, please correct me!)
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
