[Dev] Re: Recurrence discussion

Alec Flett alecf at osafoundation.org
Tue May 10 12:03:40 PDT 2005


Grant Baillie wrote:

> Hey, Alec
>
> I have a few comments (below) about this stuff. I should preface them  
> by saying that I'm not trying to make anyone revisit an engineering  
> decision (with all the tradeoffs that involves). In fact, the chosen  
> path conforms

Katie made a good point in an offline discussion about this, and I'm 
paraphrasing so hopefully I'm doing her point justice:
This is for 0.6. We may later revisit the interaction between our 
content model and our persistence layer - right now they are very 
tightly bound - if you need to deal with "Items" and all that they 
entail then they more or less have to be stored in the repository. 
Perhaps we'll have "virtual items" or perhaps there will be a way to 
have items that aren't persisted down the road. But for now, this is 
what we have.

That said:

> (1) The chosen solution persists redundant information. In almost  
> every case where I've seen this done, there arise problems when some  
> of the redundant information changes unexpectedly and things get out  
> of sync.
>
Yes, but I think some of the risk (not all of it) is mitigated by some 
unique aspects of the repository, including bidirectional references - 
the repository will maintain a certain amount of data integrity to 
ensure that we don't "loose" events into the soup, i.e. get 
"disconnected" from the main event. This is just one way we can get out 
of sync of course, but I'd venture that it at least ensures us a pretty 
stable base to work from.

> (2) There are other cases where data doesn't always fit so well into  
> the "persist everything" model. One example is supporting an "online"  
> IMAP mode à la RFC 1733 (not that this particular case is on the  
> radar for Chandler anytime soon).
>
Lisa mentioned something like this to me as well, and I'm not sure if it 
actually applies, as it depends on how we'd ultimately implement imap 
caching. I would venture that even in the "online" IMAP model, the 
client needs to maintain some amount of state on their end, and its 
unclear to me if we'd specifically not want to cache things. Many mail 
readers act in an "online" mode but cache tremendous amounts of data 
locally to improve performance... so I guess what I'm saying is, I'm not 
convinced this is an applicable case for "virtual" events.

> (3) We are choosing an implementation that doesn't scale well. If a  
> user (possibly through a typo, or maybe out of idle curiosity as to  
> what day of the his/her 40th birthday will be) jumps to the year  
> 2025, are we going to stuff 20 years' worth of recurring events into  
> the repository?
>
We don't actually know how far in advance you need to "pre-generate" 
events in order to make a "usable" product - I believe iCal's list views 
go about one year into the future and we may follow that model. Even so, 
if I'm talking about updating a string 20 times, or even 200 times in 
our database, I should hope it scales enough to make that reasonably 
responsive. I think its easy to look at "infinite recurrence" and think 
that it means a lot of data, when real world data may mean that we're 
unnecessarily generating extra events.. but really, 1000 items in our 
database should not be a lot of events... not to mention you're 
generally only UPDATING a subset of those events at one time.

Say a user has this data:
- 20 non-recurring events in the next two weeks
- 8 weekly meetings recurring oncer per week, forever into the future
- 1 event that repeats every monday/wednesday/friday, going on forever
- 10 yearly company holidays

Even for all this data, you have roughly 600 events from today until a 
year from today. And realistically, the largest subset of this data that 
you might be modifying as one unit is that M/W/F event, of which there 
are only 156 events in the next year.

> (4) Maybe I'm nitpicking here, but the mention of views generating  
> events seems to me to be mixing different layers.
>
God no. Thats more or less what we're trying to avoid.. since views CANT 
generate events, we need to generate them automatically. The only other 
place for events to be generated would be in the query system, and I it 
seems like we don't really have the bandwidth to be dealing with that 
right now.

Hope that helps!

Alec



More information about the Dev mailing list