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 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list http://lists.osafoundation.org/mailman/listinfo/dev
