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