Yes, all that looks great, Brian.
...Bryan
Brian Kirsch wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
