[Dev] Item Collection Spec 0.1

[Phillip J. Eby]

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.