[Dev] Re: Recurrence discussion
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.
> (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
Hope that helps!
More information about the Dev