[Design] Sharing the BCC field

[Mimi Yin]

Summarizing a conversation we had today on IRC: Conversation starts  
at 17:53. http://wiki.osafoundation.org/script/getIrcTranscript.cgi? 
channel=chandler&date=20060929

The current plan for Preview is to support read-write and read-only  
sharing of collections and read-write sharing of items.

+ Items are shared when users Address items and Send them as messages.
+ Item sharing is intended for non-Chandler users. Chandler users  
already have a way to edit and update items they receive via Email  
(as per the Stamping spec: http://svn.osafoundation.org/docs/trunk/ 
docs/specs/rel0_7/Stamping-0.7.html)

High-level workflow overview:
1. Chandler user addresses an item and Sends it.
1a. Under the hood, the item is uploaded to the user's Cosmo account  
and a read-write ticket is appended to the body of the email.

2. Non-Chandler user receives item in their Email client and clicks  
on the read-write ticket to view and edit the item in the Cosmo UI.

3. Chandler users receive the item via Email in Chandler and can edit  
and update the item without ever having to subscribe to the item  
share on Cosmo.

Caveats:
+ This only works if the user has a Cosmo account.
+ In the future, we will need to provide users with a way to  
selectively share individual items.
+ In the future, we will need to provide sharers with a way to  
specify read-write versus read-only access on a per sharee basis.

BUT, the introduction of item sharing presents an interesting problem  
wrt the BCC field.

I can certainly see how sharing the BCC field with certain people  
under certain circumstances would be useful. (Does anyone have any  
personal anecdotes to contribute?)

But, obviously, sharing BCC in all circumstances would be disastrous.  
(We probably don't need to collect anecdotes for this one.)

As a result, I'd like to propose a hack to address this issue in the  
short-term:

A. Allow users to decide whether they want to share the BCC field or  
not when they share collections (just like they do today with  
attributes like alarms and event status).

B. Never share BCC when sharing individual items.

B. manifests itself in 3 ways:
1. Non-Chandler user receives item via email and clicks on the read- 
write URL to view and edit the item in Cosmo UI.

Cosmo UI, when displaying shared, single items (as opposed to shared  
collections of items) never displays BCC. This means that the  
Chandler client that published the item and Cosmo don't have to know  
about hiding BCC when sharing items. Instead, Cosmo UI provides a low- 
cost way to hide BCC from casual item sharers.

2. Chandler users receive the item via email in Chandler. Chandler  
then allows the recipient to edit and update that item, without  
having to subscribe to the item share on Cosmo. As a result, the  
Chandler user is never in danger of seeing the BCC field via item  
sharing, by virtue of the simple fact that the Chander recipient  
never subscribes to the item share.

3. If a user receives an item in Chandler via email and the it turns  
out they were already sharing that item via collection sharing, then  
they should be able to see the BCC field (assuming the sharer  
specified BCC to be a part of the sharing cloud when they shared the  
collection).

Of course, this all assumes that item sharing works for Preview,  
which we're only beginning to try to figure out.

Mimi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060929/32fba952/attachment.html