[Design] In Out collection logic proposal refinements

[Brian Kirsch]

Hi Bryan,
See comments inline.

On Nov 10, 2006, at 6:19 AM, Bryan Stearns wrote:

> HI Brian,
>
> There are a lot of details to get right for in & outness, and this  
> is a great summary. I thought I'd add a couple of things:
>
> - It looks like a big performance problem to calculate in-ness and  
> out-ness everywhere you've shown we need it.

Yes, what I have done in my tree is add an isInbound boolean on  
MailStamp to match the existing isOutbound boolean.
I then put an observer on the to, cc, from. and reply addresses. When  
these values change I calculate whether the message is Inbound,  
Outbound, or both and then set the isInbound and isOutbound flag  
appropriately. The In and Out collections are simple filter  
collections. The In collection contains all mail with the isInbound  
flag set and the Out collection contains all mail with the isOutbound  
flag set.

Does this sound reasonable?

> I think it makes sense to go back to representing in-ness and out- 
> ness as separate booleans, on ContentItem; we can use  
> schema.observers on the various attributes that affect them, and  
> perhaps a mechanism like we use for updating displayDate to allow  
> the various stamps on an item to contribute. Also, as we've said  
> before, changes to configured 'me' addresses on email accounts will  
> probably require a separate sweep of items to update email items.

Yes, this is the one case where an additional scan is needed.

>
> - Those in and out booleans won't be shared: each Chandler will set  
> them up (automatically) when a new item is received (via sharing or  
> email). If I'm sharing with myself and both Chandlers are  
> configured with the same email accounts, I'd see the same contents  
> of In and Out.

Yup, the in and out flags are not shared.
>
> - It would simplify handling of corner cases in the short term to  
> at least make the 'In' and 'Out' collections read-only for Preview  
> (so no 'New Item', no dragging in); I know Mimi has longer-term  
> goals for unified In and Out (beyond just mail) that would be  
> easier to transition to if users didn't have ingrained In- and Out- 
> manipulating behavior.

+1

-Brian
>
> ...Bryan
>
>
> Brian Kirsch wrote:
>> Hello,
>> This discussion comes from bug 6857: In and Out collections should  
>> compute their contents based on the sender or recipient of an  
>> email, not the isOutbound attribute.
>>
>> http://bugzilla.osafoundation.org/show_bug.cgi?id=6857
>> [...]
>> I would like to refine the exact definition of the In / Out /  
>> Dashboard logic to the following:
>>
>> In Collection
>> -----------------
>> 1. Contains all mail received via the Mail Service.
>> 2. Contains any mail item where one or more of the 'me addresses'  
>> appears in the to or cc address.
>>
>> Out Collection
>> -----------------
>> 1. Contains all mail items composed in your instance of Chandler.  
>> What this means is it must contain
>> one of the 'me addresses' as the from or no address if the mail  
>> accounts have not been set up. This covers the case where a user  
>> composes a mail message before entering in his or her mail account  
>> information. A user can never enter an address in the from field  
>> that is not in the 'me addresses' list.
>> 2. Contains any mail item where one or more of the 'me addresses'  
>> appears in the from or reply address.
>>
>>
>> Dashboard Collection
>> -------------------
>> 1. Contains mail composed in your Chandler. Is this the correct  
>> behavior?
>>     Do we add all mail in the 'Out' Collection or just those you  
>> personally composed?
>> 2. Contains all mail received via the Chandler Mail Service.
>>
>> The sending replying rules would remain the same but be applied  
>> against the new 'In' and 'Out' collection behavior.
>>
>> The rules are:
>> 1. All mail in the 'Out' collection which has not already been  
>> sent is sendable.
>> 2. Al mail is the 'In' collection is replyable and forwardable.
>>
>> I also came across an interesting bug. No matter which Tab I have  
>> selected in the Toolbar (All, Mail, Task, Calendar), if I have the  
>> 'In' or 'Out' collection selected in the sidebar and hit the New  
>> button an item of that stamping is created in the collection. This  
>> obviously not the right behavior.
>>
>> I would assume going forward that this action would be disabled.  
>> The 'In' and 'Out' collections are Read only and calculated by the  
>> coder. Thus a user should not be able to drag any item in to the  
>> collection or create new items in the collection manually.
>>
>> So what should happen if a user hits 'New' in one of these  
>> collection or tries to drag an item in to the collection? What  
>> should the app do? Display a alert warning? Ignore the request?
>>
>> I will also post this to the design list so others may voice their  
>> input.
>>
>> -Brian
>