[Dev] Recurrance discussion

Mike Taylor bear at code-bear.com
Mon May 2 17:42:39 PDT 2005

The last time I did something like this in code (not python 
unfortunately) I had to query from the database to get those items that 
had been "touched" in order to build a month/week view.  Once an item 
had been edited in any way it was written to the database for storage, 
otherwise it remained virtual.

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.


Open Source Applications Foundation (OSAF)

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.osafoundation.org/pipermail/chandler-dev/attachments/20050502/0e78c250/PGP.pgp

More information about the Dev mailing list