[Design] Sharing the BCC field

[Brian Kirsch]

Hi Mimi,
See comments in-line.

Mimi Yin wrote:
> Summarizing a conversation we had today on IRC: Conversation starts at 
> 17:53. http://wiki.osafoundation.org/script/getIrcTranscript.cgi?channel=chandler&date=20060929 
> <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.

Just an FYI that this could result in mail messages taking a long long 
time to send. The mail message send logic must wait for the Cosmo logic 
to complete in order to get the ticket info to send with the message. 
This could be a performance concern.

 If Cosmo is down what happens?

Now having said that these operations are performed in the background. 
But the case will occur where a minute or two after hitting send on a 
message an error dialog could arise such as "Could not send mail because 
sharing upload failed to Cosmo server." Again, I only mention this as an 
FYI.


> 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?) 
>
I disagree that the usefulness is great enough to warrant all this 
custom programming logic which will take up developer resources.

I would like to suggest that we do not share BCC: under any 
circumstances with the exception case being the original sender of the 
message syncing to retrieve lost data. I.e. a Chandler upgrade or crash 
requires re-fetching the items from Cosmo.

Until we have concrete feedback from users that they really do want to 
share the Bcc: info I don't think it is worth the time when we have so 
many other tasks on our plate.

It also could be a springboard for negative press if by accident / bug 
the Bcc: was shared / sent to someone who was not suppose to see it.


That is my two cents :)

-Brian





> 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
> ------------------------------------------------------------------------
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design
>   

-- 
Brian Kirsch 
Internationalization Architect / Mail Service Engineer
Open Source Applications Foundation
543 Howard Street 5th Floor
San Francisco, CA 94105
http://www.osafoundation.org