On Mon, 18 Jun 2007, Bryan Stearns wrote:
- Why does each view need its own timezone? I understand that indexing requires tying the floating timezone to a particular timezone, and that reindexing is necessary when the particular timezone changes, but it seems simpler to force the change to happen in lockstep (one view reindexes; the rest wait during indexing, then refresh) than to allow every view to have its own timezone.... partly because I don't understand how the reindexing can work:
Say the UI changes the default timezone by setting ICUtzinfo.default like it does today. The UI also takes care of reindexing the sensitive indexes. All good so far, in the UI view. In the meantime, the background sync that was in progress also got its default timezone changed since it looks at the same ICUtzinfo.default global but it didn't notice the change. Its sensitive indexes are now out of order, the floating events haven't floated anywhere. It could still recover index sanity if it makes no changes and refreshes immediately, it would then get the reindexing results from the UI. But if it does make changes, or if it has made changes already, these changes are made to now invalid indexes and all bets are off.
The main point here being that each view needs to have its own default timezone until it commits, it cannot be shared by a global since the consequences of its changing are not shared until refresh.
- You say that when one view's timezone changes, reindexing occurs. Indexes are persisted, though - doesn't that mean that views will fight over this? Or will we end up with an index per timezone?
A view's default timezone is persisted but a view's timezone only stays different from the newest view's until refresh. At refresh time, the view's timezone becomes the timezone of the latest view.
In other words, all views can be thought of as different versions of the same item, there are no competing values for timezone, just different versions of it.
Andi.. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
