I finally have had a chance to come back and revisit this issue.
The new sharing framework does much more than the old one did in
terms of dealing with differences between local and external values.
There "server wins" approach is no more. Instead, if an external
change is in conflict with a local change, the external change is
flagged as a pending conflict and will show up in the new conflict
resolution dialog. Pending conflicts can be resolved by either
accepting them, discarding them, or they can even auto-magically go
away if someone else happens to change the value to the same thing
you did. You can also ignore a pending conflict for as long as you
want, and resolve it later.
The new filtering mechanism is, in my opinion, a huge improvement
over the old one. With the old one, everyone participating in a
shared collection was required to use the exact same set of filters.
For example, if one person decided to share reminders then everyone
else got those reminders as well, even overwriting any local
reminders you had set. The new EIM-based sharing framework allows
each sharing participant control over what individual fields they
want to "opt out" of sharing. Also, if I originally opted out of
sharing reminders when I subscribed to a collection and later change
my mind, when I check the reminders checkbox in the Collection Manage
dialog, any reminders currently on the server that differ from mine
will be flagged as a pending conflict -- no data loss caused by the
old "server wins" model.
Finally, there are new capabilities for the read-only subscriber.
Since the new framework is able to maintain differences between local
and external changes, we can now actually allow the read-only
subscriber to locally modify any field on an item. The old framework
was too hard to explain: a user could not modify a given attribute if
the item was only a member of read-only shares and the attribute in
question was either not one that the sharing layer knew about or if
the attribute happened to be filtered out at the moment. The new
framework doesn't have such a limitation: if the user wants to add a
few lines to the body of a "read-only" item, they are allowed to. If
someone later makes a change to the same body, that external change
will be flagged as a pending conflict. Or you might normally want to
get reminders on a certain read-only calendar, but be able to
override them on individual items. You can do that now. Given this
functionality, we should probably have an affordance for allowing the
user to decide they want to make any change to a read-only item --
perhaps using either the little pencil icon at the top of the detail
view, or perhaps the "never share" lock could be repurposed.
Something to let them know they are choosing to override a value on a
read-only item. As implemented now, the user can go ahead and make
the overriding change.
So given this new functionality, let's talk about the need to
transmit filter information, at least for Preview. I propose we make
it the default that all fields are shared (all checkboxes checked)
both for publish and subscribe. If you want to opt-out of sharing a
field, you uncheck the appropriate checkbox. As for read-only
subscribers, let's look at an example field like triage status:
either you are filtering it out or you are sharing it (as you
selected in the subscribe or manage dialogs). If you are filtering
it out, you are free to edit the field, and you won't see anyone
else's triage changes, nor get conflicts. If you *are* sharing it,
you will see other people's triage changes *and* you are also able to
override the field; if someone else later on makes a change to it you
will get a conflict notification. So for read-only subscribes, we
can definitely get away with not knowing what filters other people
have in place. For read-write shares, if you are filtering out a
field, you are free to edit it, your changes won't be sent, you won't
see external changes to it, and will you get no conflicts. If you
are sharing a field, you are free to edit it, your changes will be
sent, you will see external changes to it, and you can get
conflicts. The decision for what filters to have in place is really
up to each individual: if you don't want to share a field, don't
share it.
Oh, and I don't think hardcoding the filters for Preview is a good
idea. Can we really force people to share the BCC field? I doubt
one combination of filters is going to meet people's needs.
On Mar 27, 2007, at 6:10 PM, Mimi Yin wrote:
Hi Sheila,
Basically the UI blocker is the filter inconsistency between the
sharer and the sharee. I don't think we can have people not knowing
what attributes they're sharing with each other.
Can we do something like hardcode what's shared and not give users
options for Preview? I would prefer that over users not knowing
what they're sharing.
Would it be acceptable to always share:
+ Triage status and alarms
+ BCC
+ Needs reply
And never share:
+ Event status
Mimi
On Mar 27, 2007, at 5:51 PM, Sheila Mooney wrote:
Mimi,
Is this a definite blocker for Preview? I understand the workflow
and motivation but we are pretty much down to the wire with
feature freeze on Thursday and this currently isn't on Morgen's
task list. Although I understand it's not ideal, could we get away
with NOT doing this for Preview and relnote or add some explaining
in the documentation?
Just exploring whether or not this is an alternative.
Sheila
On Mar 27, 2007, at 5:04 PM, Mimi Yin wrote:
I think we need to make sure that the sharer's filter preferences
are getting to sharees. Otherwise, as a read-only sharee, my
Chandler won't know whether or not it should allow me to do
things like edit Triage status, etc. Also as a sharee, I need to
first see what the sharer's preferences were before deciding
whether I want to override any of their filters.
Logged as bug: https://bugzilla.osafoundation.org/show_bug.cgi?
id=8514
On Mar 22, 2007, at 2:53 PM, Morgen Sagen wrote:
On Mar 22, 2007, at 2:26 PM, Mimi Yin wrote:
As for "Show Sharer's options first", I wonder if that's fairly
important. Is this something we won't have on the server for
Preview? Or just temporarily as you finish up EIM?
This wasn't something I was planning for Preview, no.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
