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
I have to put a little more thought into how we can phrase the requirements for stamping and reminders. I would point out that our key focus for 0.6 is making recurrence work for the calendar. We need to not break stamping, but it would be reasonable to not support complicated edge cases in the ideal way for 0.6. Reminders are another story, as they are important for a usable calendar -- supporting reminders is a first class requirement for 0.6.
Bryan -- I'm still following up with my contact; Lisa's data points are interesting.
Cheers, Katie
Bryan Stearns wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
