Sharing Discussion

• Led by Morgen Sagen, Phillip J. Eby, Brian Moseley
• Notes taken by Priscilla Chung

Session Notes

Sharing requirements (end user requirements) - Specific to the beta time frame.

• What are the beta requirements

What do we want to share

• Share collections
• individual items (notes, tasks, events, communication)
• stamped items (all derivatives
• share Chandler specific types
  • stamped
  • any time events
  • @time
  • gobbley gook in date/time, to/from fields
• primary + secondary items
• communication status
• subscribing/publishing to multiple sharing accounts

• restore desktop world locally
• events be queriable by FB
• cancelled meetings, organization, participants (translate chandler attributes)
• not having to re-share
• tracking who when and what? –item

What we won't share

• tags (other than tag pointing to collection you are sharing
• read, unread, needs reply
• not supporting the same person having multiple Chandlers on different computers
• on Cosmo UI, if you change an item that is in more then one collection- the desktop user needs to sync to reconfigure the two items (not the end game-not to jump hurdles now to do it)

Optional

• alarms
• event status
• triage status

Non-functional requirements - Issues

• Jared: reduce the # http transactions
• improve performance
• contacts/3rd party parcels

Sharing format proposal

• Phase I
• Key for Phase II in Cosmo is to identify Chandler UUID.
• The client make the UUID
• Performance (non design related changes)
• Not doing the 2 forks, simplified. One client updating, restore half the amount of storage. If was ever want another client, there is not way to get some data from one client and another from another client.
• This cuts the volume by 50%
• Morgen: will will continue to be a CalDAV client.
• How important is it to interop with a CalDAV, a server that can only share events.
• Is the format going to change be difficult to handle old clients
• Phase I is incremental steps

• Jared: is the beta timeframe
• Sheila: problems with incomplete
• Mikeal so many request, cut down on time to share
• Ted: Time share is very important. Background sync, can cut down the time in half
• Mimi: If we just do phase I, we can live with it. Though it may be insufficient.
• Sheila: If we skip phase I, there is risk there because we're counting on the soup thing
• Morgen: What can we do to help the performance?
• BCM: We should be able to
• Jeffrey: Is PUT the
• Bobby: PROP finds
• Ted: We might get unrelated
• Jared: Kill white space, half of it is indentation
• Ted: Or not generate at all, uses up CPU

External information model framework

• Led by Phillip J. Eby (PJE)
• http://wiki.osafoundation.org/bin/view/Projects/ExternalInformationModel
• when new data is added, a nice way to manage backwards compatibility
• intended application dev, can write one set of code to define on set of format
• internal abstraction table and rows (not methods) plain data, point for a dev to say this is the version so far
• time-zones formats not settled
• can extend to Cosmo,
• Jeffrey: Phillip are you want the info model abstraction?
• BCM: This is not a concept JCR is reflected, logical doc. model. A way of thinking how the structure is together. The more I listen to what you say, it makes sense for Cosmo/Chandler to share that. Inside the system, allow the same kind of extension Chandler does. How it will be transmitted back and forth.
• Morgen: that decision, record based or item centric
• BCM: There is no reason why we choose one over another.
• Morgen: More efficient to have the transform on the wire.
• BCM: I don't have anything negative to the proposal. Server side logic for differentiation
• Morgen: So the EIM model.
• BCM: 4 - 6 months, hibernate against relational database
• PJE: you can do interesting thing with quires
• BCM: hibernate work based on, it's a event, or a, not supporting the stamping model - yet. Moving to the EIM style, we need to get there. This is a good way to get us to there
• PJE: Grant is changing the way we are type of an object then acts more neatly, stamps become records 1:1. Relational mapping.
• BCM: very similar to SimDesk^? (randy/charles) a way forward.
• Ted: We don't have a data model for the client side for the web, using this for the desktop, exchange format and the data model for the
• Matthew: both clients are being developed
• BCM: we should continue using DAV, but not tie ourselves to it. Look at replacing the DAV, GET/PUT things. Help us remove the DAV model of what we are doing. Good for now, and move away from it at another stage
• This will help us to get to where we're want to go in terms getting the user's information partially opposed to
• Mimi: how does this map to what the user sees? Or stamps what the user's? Something like a book mark is a data type.
• Katie: We're unifying the model.
• PJE: record types represent according to their interfaces instead of according to their types. We need to process super interfaces the sub interface. You cut off the tree at the edges
• BCM: chandler will use this as a dump and reload, Cosmo will use the same way as well.
• Morgen: we can have a stream a record for
• PJE: write all the records. All of the data contained in one file
• Mimi: downloaded 3rd party parcels. How do you share something when someone has not downloaded the parcel? How does a user understand that they either need to download the parcel?
• Ted: Not defined. Not useful. For beta, we haven't talked about parcel install.
• PJE: we can add some data to add a link to the originator of the record types being shared. Oh you can download this thing from here.
• Ted: at a prod. planning level. we have not thought about it.

Next Actions

• To move forward with the EMI proposal.
• External information model for Cosmo

Questions

• How fast can it be done?