Sounds like we would have to do something along the lines of passing the base/parent item to a sparse array mixin that then queries to fill in any spots that represent those events that have been modified in any way and therefore persisted.
--- Bear http://code-bear.com
Open Source Applications Foundation (OSAF) http://www.osafoundation.org
PGP Fingerprint = 9996 719F 973D B11B E111 D770 9331 E822 40B3 CD29
On May 2, 2005, at 8:18 PM, Ted Leung wrote:
I assume that we want multiple items so that things like the detail view get hooked up properly?
If we end up going with the multiple item model, then how does materialization of virtual recurring events work?
Let's say that you want to render a month view for the calendar and since the last rendering the user has created a recurrence that impacts that month. Before you can retrieve the events for that month, you have to ensure that all relevant recurrences have materialized the relevant events for that month. Whether we do the retrieval via a query or some other means isn't really the issue. It's having to do the materialization and possibly remember which instances have been materialized, although having a biref to the recurrence object probably helps with that. I suppose that we could try to push materialization into queries somehow, but I'm not sure that's the right solution either.
Ted
On May 2, 2005, at 12:34 PM, 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
---- Ted Leung Open Source Applications Foundation (OSAF) PGP Fingerprint: 1003 7870 251F FA71 A59A CEE3 BEBA 2B87 F5FC 4B42
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
PGP.sig
Description: This is a digitally signed message part
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
