Edit/Update 0.7alpha5 Development Tracking

Since this feature is so critical to Preview and involves so many people, we decided to track its progress more closely so that we can identify blockers more easily and act accordingly

People

BKirsch, PJE, Morgen, Grant, Reid, Philippe (coordination)

Communication

We'll hold a daily check point on IRC on the Chandler channel every morning at 11am.

Tasks

Task	Assigned	Status	SWAG	ETA	Dependency
Use sharing code for email updates	Brian, Morgen				Morgen and Brian need to determine what API is needed for per user shares on an Item. There is also a dependency on the conflict UI .
Chandler to Chandler headers	Brian	Done but not yet checked in.			None
EIMML field model	PJE
Store "pending changes" in schema	Grant
Modified state (edited by, etc...)	Grant
Comm state (draft, read, etc...)	Grant
Toolbar changes (Send/Update)	Reid
DV changes : byline	Reid
DV changes : show "conflict error" banner	Reid
Conflict resolution UI	Reid
Triage updating	Bryan

Notes

1/17/07 conf call

Current decisions/design:

• EIMML doesn't need the before/after bundle anymore but just a snapshot of the current item and a revision ID
• Changes carried around by EIMML are per "field", "field" are a lower level description level than attributes and do not necessarily match attributes (in the general case)
• In the current case though, "field" and "attribute" almost all match except for recurrence info
• "pending changes" are unique per item per share, so, we can have for a particular item, several pending changes record, i.e., one per share the item belongs to. In the case of emailed changes, each sender is considered as a "share".

Elements that do need special UI work/design:

• An item can't be updated through email as long as there are unresolved conflicts pending, so it should be "read-only", waiting for conflicts to be resolved
• Delete and unstamping do clear lots of attributes at once making a "per attribute" UI a little difficult to manage
• Recurring events are complicated conflict resolution a great deal since changes can be applied to a multiplicity of items on the user machine, generating conflict for some items and not others
• Recurring rules changes are not human readable so a simple "show the field changes and allow the user to cut and paste" solution is not realistic
• 3 way conflicts: the merge model can only handle 2 ways conflict (user with 1 collaborator at a time). In case of several pending changes (remember, we have one per "share"), conflict will have to be resolved sequentially. This means that conflict need to be reevaluated (a previous resolution could make a remaining pending conflict moot).

1/22/07 conf call - draft, meeting @ 3:30pm

Objective: get to an agreed upon design so that PJE and Morgen can devise the relevant API to support it.

Review "simple case" solution and limitations

• Mimi sent a proposal for simplication.
• Difficulty is to find what are the attributes that are affected by the fields changes
• Reframing the design so that we focus on no data loss
• UI would be to display the changes and allow you to cut and paste from them to the DV. The user can then "resolve the conflict" globally.
• PJE: easier to design if we apply/reject one person-conflict at a time
• Next action: Mimi to propose something, think she has everything to mock up a UI now

Conflict when the user deletes an item and then a conflict on it is received

• The item May need to be recreated in the collection (in which case the delete you did is now pending...)
• Actually, the pending changes are added to the item which is in the user trash
• Add icon to the sidebar when you have conflicts in a collection? Seems to be a good idea (need to check with John)
• Long discussion on related issues with remove (from a collection) vs. delete
• Emptying trash: need to prevent to empty items that present conflicts
• Next action: PJE and Morgen to continue working on this

Recurring items added complexity

• Grant gives an update of his thoughts on the subject. Issue with "Future" events: we create a new serie of events in that case.
• Case where we loose data: change an occurence in 2 weeks and receive an update for next week marked "All Future", your change is lost
• Conflict is surfaced at the master level only
• Discussion on using UUID or namespace UUID
• For single modification, we could orphan events in some situation (have off rule occurences)
• Next action: Grant to write on "off rule occurences" and "model for this and future changes"

Questions

• When do users see items they've deleted if there's a conflict? Their version of the item won't be visible anywhere except the trash. -- JeffreyHarris

1/26/07 conf call - meeting @ 2:15pm

Morgen still not there so most of the questions will be asked tomorrow during the Design session on Conflict UI qand/or on email to Morgen. Brian K asked some questions to PJE though:

• Doing the outbound to several people, what should we do for state? Need to track the state object for each peer. Shouldn't send to anyone you have pending conflicts with. Really a Morgen question (will reask tomorrow).
• EIML translator: how to find the item UUID that was received via EIM? API level question.
• Should we save things like read/unread (which are also IMAP states)? Not for Preview, emails (and items they transport) are marked unread when first read from the IMAP server, even through "Reload" (as in "Dump and Reload").
• How to apply a filter to outbound items? Need to be exposed at the right level. Another Morgen item.

References

• Stamping spec : contains the Edit/Update scenario description
• Dev Docs

-- PhilippeBossut - 16 Jan 2007