[Chandler-dev] IRC QA session, Wednesday, April 25th 11:00 AM PDT

Aparna Kadakia aparna at osafoundation.org
Tue Apr 24 22:15:43 PDT 2007

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  
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  
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


> From: Morgen Sagen <morgen at osafoundation.org>
> Date: April 23, 2007 5:11:21 PM PDT
> To: Chandler Design list <design at osafoundation.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.

More information about the chandler-dev mailing list