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".
-- 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.
These sorts of questions aren't really covered in the spec as yet, but they
were things that Ted and I talked about while I was in SFO a month ago, so
I was curious about the outcome.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
