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.osafoundation.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 <[EMAIL PROTECTED]>
Date: April 23, 2007 5:11:21 PM PDT
To: Chandler Design list <[EMAIL PROTECTED]>
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.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
