[Dev] Item Collection Spec 0.1

[Ted Leung]

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