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