OpenSocial 3.0 Summit Minutes

Agenda: OpenSocial 3.0 Summit

Attendees:

- Erskine Williams (Jive Software)
- Matt Franklin (Mitre)
- Jesse Ciancetta (Mitre)
- Mark Weitzel (Jive Software)
- Jason Gary (IBM)
- Matthew Marum (IBM)
- Andrew Davis (IBM)
- Andy Smith (IBM)
- James Snell (IBM)
- Ryan Baxter (phone... IBM)
- John Petersen (Sutro Software)
- Craig McClanahan (Jive Software)
- Henry Saputra (Jive Software)
- Stas M. (Sugar CRM)
- Evgeny Bogdanov (phone, EPFL, Lausanne, Switzerland)
- Daniel Risacher (phone, Office of the DoD CIO)
- Howard ??? (On phone)
- Matt Tucker (Jive Software)
- Mark Halvorson (Atlassian)
- Ellen Feaheny (AppFusions)
- ???
References

Discussion about spec release timelines and scope

Spec Changes - v2.5
Spec Changes - v3.0
OpenSocial Specification Roadmap

Update development process to require JIRA ticket on Shindig to have the spec implemented. Link to this in the spec.
We need to encourage the contribution of prototypes to Shindig. (But not required)

March is first draft of 2.5
Monthly Implementors Draft's after that.

Metadata Service

Rule for deprecation - you must have replacement API incubating before you can deprecate API
Assign owners for spec issues to be implemented

Metadata service - incubating in 2.5

Rename “metatdata service” to something else (Environment/Object metadata?) to avoid confusion with gadget metadata service

Created issue for metadata service & assign to craig (Issue 1261)

Common container discussion

Can we move it out of incubating in 2.5?
Henry & Jesse - there’s some bugs that need to be worked out in Shindig and cleanup that needs to get in - but feel that Container API is ready.
Andy - We need to be careful that we aren’t using spec to document our APIs
Mark - Consensus is - Let's do it.

Embedded Experiences

Andrew - Showed 6 different partner demos using EE
We don’t want to lose momentum, tutorials & videos are vital to get better adoption. That was a big lesson we’ve learned

Mark - Jive has started implementing EE and have identified new use cases
see wiki for proposal

After much discussion - there was a consensus to add a new key to the data context to allow the gadget to get the “parent” context so it can get more information about the container and application context.
Add new fields to embed, labels, parent type, abstraction, etc.
what this looks like is still TBD.

Spaces proposal

Evgeny presenting via web conference

We should make sure that Space IDs use IRIs as we are trying to move towards using IRIs as IDs throughout the spec.
Mark - Maybe we need to add an osapi.apps.* for things like context, etc.
Mark - Lets focus on javascript APIs for Spaces for now and revisit REST APIs once we’ve revamped them

David - Can we add a space to the social graph?
Can a person “follow” a space? Are they part of the social graph.
Howard - Spaces can own resources, so they need to be a full actor in the graph

We need to clarify role of AppData.. what does it mean in Spaces.

David & Howard - We need a more general idea of what a resource is, because any resource may have an activity stream associated with it, etc.

Editor discussion

James - We need an editor, there is a need for clarity. Somebody needs to come in and fix the editorial problems in the spec. To be clear, not changing the technical meaning of the spec. Raise new issues on spec list when necessary.

James Snell & Matt Franklin nominated to be Co-Editors.

Versioning

Using Link header to identify version
Use mime types to version social data formats
Upgrade header can be used to notify apps that they need to upgrade

From REST perspective - we are happy with using Header to identify protocol version, Gadget API versioning needs more discussion

Lets do Link: header in 2.5. Use of “Upgrade” header , media types, should be incubating

REST API

James presented his ideas on how to revamp REST APIs. Backwards compatible.

Concerns about how the proposal handles batch and what the expected response is for example.. what is response for “/user1,user2/ (friends,)followers”?

Parts of this could be added as incubating in 3.0.
New URI definitions, add support for PATCH, deprecate what’s in there today for partial updates.

Adding group models

Fine. We should be adding a registry on the wiki, something we need to do for 2.5

Deprecate XML support

If we were building an API today, would we even support XML? None of our XML schemas are complete and we insert extensions into data models in all sorts of places.

Deprecate XML in 2.5, we will remove it at some point TBD (3.x or later)

Adding label to Plural Fields

All plural fields will have a label

- Do we need a registry for extensions, etc. We need to define how extensions to OpenSocial models should work. Reverse DNS, etc. Need to do this in 2.5.

Defining Resource links..
if we’re doing PUT/PATCH, we should add a type field to the resource links

3.0 - we incubate resource links on social data objects.
- we add resource methods, javascript methods based upon resource links.

We want require 1 implementation in order to cut an Implementor’s draft for a spec change.

Simplification of the Entire Spec

We’re looking at how we want to restructure the specification. A lot of discussion of how to break it down. There’s definitely need for an OpenSocial primer or additional Tutorials, etc.

We might want to table this until we’ve done heavy editing of the spec in 2.5.

OpenSocial Foundation