On Jun 2, 2005, at 4:58 PM, Phillip J. Eby wrote:
At 04:12 PM 6/2/2005 -0700, John Anderson wrote:
Phillip J. Eby wrote:
At 01:54 PM 6/2/2005 -0700, Ted Leung wrote:
On Jun 2, 2005, at 1:38 PM, John Anderson wrote:
Phillip J. Eby wrote:
I'm wondering about the "post(sourceItem, targetItem, methodName,
Event)" API; wouldn't it be simpler just to pass a callable, i.e.
"post(sourceItem, targetItem.someMethod, event)"?
If I'm not mistaken, this information needs to persist and I don't
think the repository has a datatype that persists a callable.
Yes, persistence is the reason.
Okay, I missed that bit, probably because it's not really tied in
to the rest of the spec. Why is it persistent? How does that
relate to the use cases there? I didn't get that part at all.
In what view(s) is the event invoked?
If it's persistent it's simpler
Not if the need for notification is dependent upon the recipient's
visual state. For example, the detail view only needs notification
about a particular item, and only while it's displaying it. So
persistence in that case isn't "simpler".
The current version of the spec doesn't try to solve the detail view
problem. However, Phillip reminded me that we had talked about a
Value Model based solution to this problem, and I've been looking at
some documentation on Value Models <http://c2.com/ppr/vmodels.html>
to see whether this would be better than having the detail view/
attribute editors use monitors.
-- both because of how items work, and
because you don't need to add and maintain code that initializes
it when
Chandler starts.
It's not clear in the spec that the proposed notification system
needs this. For example, for a union of two sets, a pull-based
notification system would only need to ask its two downstream sets
for changes since its last update. It doesn't need to be notified
of every change to those two sets, unless there's something
expecting immediate notifications from it.
Right now, what I proposed is a hybrid push/pull approach, where
notifications are pushed into a queue and then released by a trigger
(which happens to be in the idle loop). This is conceptually similar
to a BufferedValueHolder in a Value Model oriented view of the
world. Given that hybrid approach, we would still need to
initialize the structure of the notification network. However, I'm
somewhat unhappy with this part of the design because of some of the
discussions that Phillip and I had last month, and I'm open to being
convinced to a different spot in the design space.
Ted
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
