[Design] Sharing the BCC field
sheila at osafoundation.org
Mon Oct 2 16:33:59 PDT 2006
On Oct 2, 2006, at 1:00 PM, Brian Kirsch wrote:
> 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://
>> 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://
>> *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.
We talked about this during our IRC conversation. Morgen also
expressed concern about performance if we assume any item that is
sent to another user needs to be shared on the server as well. In
some cases people will only be sending these items back and forth
with other Chandler users and they don't need to have item URLs. I
think this needs to be some kind of option (to create a URL) and
probably not the default state. Users would do this explicitly. This
should help with the performance issues. I believe Mimi is working on
some wording for explaining this to the user.
I think in the case of a sharing error (ie: cosmo down) we could give
users the option to send it anyway...just as an email. If you created
an event and sent if for the first time and the publish fails, the
recipient would simply get an email with an ics attachment but no url
to click on. This is fine. The motivation behind the item URL is
really so people can participate in the collaboration experience
without using Chandler, they could use the Cosmo UI to collaborate on
at item instead.
We realize sharing items, although a neat idea, has some challenges.
We would like to spec it out anyway and go through the process of
teasing out all the issues even if it's not doable in the Preview
>> 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.
>> + 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.
How is this different than the other attributes that are optional in
the sharing cloud ie: alarms, event status? Morgen, any comments?
> 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.
Mimi is simply thinking through the workflows and how this might work
in the long-term. Discussing this on the list is the right thing to
do but it certainly doesn't mean it's a must have for Preview. It
will have to be prioritized along with everything else and as you
pointed out, there are many other tasks on our plate. We have already
talked about not sharing the Bcc field at all for Preview. We simply
wanted to explore it a bit further.
> That is my two cents :)
>> But, obviously, sharing BCC in all circumstances would be
>> disastrous. (We probably don't need to collect anecdotes for this
>> 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.
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "Design" mailing list
> Brian Kirsch Internationalization Architect / Mail Service Engineer
> Open Source Applications Foundation
> 543 Howard Street 5th Floor
> San Francisco, CA 94105
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Design" mailing list
More information about the Design