Hello Everyone,
This is a reminder about another collaborative QA session
which wil
be conducted in the #cosmo channel at 11:00 AM PDT.
We are in the final integration testing phase of the Cosmo
0.6.1
release. That means we will be collectively testing the
morsecode/
eimml based sharing against a cosmo 0.6.1 server.
The qa machine qacosmo has been upgraded with the latest
cosmo build
and will be used for sharing and subscribing to calendars.
Here's the configuration:
Server: qacosmo.osafoundation.org
Path : /cosmo *Please note this*
port : 80
no SSL
Here are the steps to follow for the QA session:
1. Get latest version of Chandler
2. Get an account on http://qacosmo.osafo
undation.org
3. Setup the Chandler Hub Sharing account in Chandler to
point to
qacosmo
4. Publish calendars on qacosmo
5. Post the URLS in the #cosmo channel for people to
subscribe
6. Make edits to the events in the shared calendars
specifically
around recurrence modifications, timezones, stamping etc
7. Sync the collection and validate with the changes do
propagate
accurately.
8. Create conflicts and make sure those appear correctly in
the
detail view UI
Attached below is an email from Morgen that he had sent out
last week
that explains in great detail on how things are expected to
work in
the new sharing world
Thanks
Aparna
> From: Morgen Sagen <morgen osafoundation.org>
> Date: April 23, 2007 5:11:21 PM PDT
> To: Chandler Design list <designosafoundation.org>
> Subject: Re: [Design] Adding the filtering checkboxes
to the
> subscribe dialog
>
> 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.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev
|
