[Dev] Item Collection Spec 0.1

[John Anderson]

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".

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.

>
>
>>  -- 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.
>