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