[Dev] Item Collection Spec 0.1

[John Anderson]

Phillip J. Eby wrote:

> At 05:44 PM 6/2/2005 -0700, John Anderson wrote:
>
>> Currently notifications fire only for UI that's visible. However, the 
>> way the repository works today makes initialization of non-persistent 
>> data hopelessly complicated -- we spent many man months trying to 
>> make it work before giving up and going with the persistent model, 
>> and since then life has been much better. Some of these problems 
>> could be address by changing the repository, however, I haven't been 
>> able to make that happen.
>
>
> And that's a fine answer, if that's the reasoning behind the 
> proposal.  It just wasn't in there, and "if it's persistent it's 
> simpler" didn't convey that information either.
>
> However, I'm confused as to why you say initialization of something 
> like that would be complicated.  The visual components receive 
> messages that tell them they're being shown or hidden, so that seems 
> to me like it would be an obvious time to activate or deactivate a 
> subscription for notifications.  This doesn't have anything to do with 
> "initialization of non-persistent data" in the general sense; only 
> visual components in particular.

This is actually how it works today.

Experience has taught us that adding non-persistent attributes to items 
is usually a mistake for the following reasons: Non-persistent 
attributes get deleted whenever items are pruned from memory and it's 
often impossible to recreate them without saving the information 
somewhere, e.g. a persistent attribute. Currently, there are several 
places that you need to initialize non-persistent data: when an item is 
loaded, when it's copied, and a few more I can't remember--all similar 
but slightly different. I've lobbied Andi to combine them, but so far 
haven't succeeded. If you make certain repository calls during 
initialization you die in mysterious ways in the repository, mostly 
because of unexpected recursive calls in the repository caused by 
"chicken and egg" problems. You may be familiar with this problem 
because it often occurs in the middle of constructing objects when one 
object depends on another, which isn't fully constructed. Fortuanately, 
switching over to the persitent model elminates the "chick and egg" 
problems since initialization happens when the initial repository is 
constructed, e.g. parcel xml.

>
> Such an approach avoids the need to commit the subscribes and 
> unsubscribes to the persistent store as the component's visual state 
> changes, for example.  It also avoids the issue of persistent 
> callbacks occurring in multiple repository views; instead the callback 
> could be view-specific.
>
Commits are unnecessary since all the callbacks are in the ui thread and 
we're doing refreshes in idle, so we also get notified when other view's 
commit their changes.

Today, we only do commits at "undo points" in the UI thread. Other 
threads do commits whenever they want the items to be available to other 
threads, e.g. the ui thread.