Spec Changes
Overview
All changes to the OpenSocial spec are proposed, discussed, and voted on in the spec list.
To look at changes in the previous iterations, please look at:
Spec Process
Adding proposals to the OpenSocial specification may follow many paths, but below is the basic overview.
- Come up with a bright idea.
- Create a functioning implementation or extension (preferably in Apache Shindig) that embodies the ideas and can be evaluated by other people.
- Write up a page in this wiki that describes the proposal and outlines some use cases
- Start a discussion thread on the OpenSocial and Gadgets Spec group (link with proposal wiki page).
- Iterate on prototype and proposal to include community feedback
- Create a new Issue on OpenSocial-Resources project. (link with proposal wiki page and in discussion thread)
- Add a link to the specification-scope document in svn specification-scope in svn.
- Modify the spec document(s) to include your proposal. Surround all changes with <x:draft> tags.
- Create a patch file with svn diff and attach to the Issue
- Check in the changes to the spec. Comment must include the issue number and identify proposal - ex: Issue NNN
- Designate that revision as the voting revision and link with the Issue. Make an announcement on the discussion thread and link from the wiki proposal.
For information about the spec process itself, please see the Specification Process. The process for voting on proposals is here documented on the Voting on Proposals page.
Prototype proposals and vote on their specifications
Once the set of proposals for a given iteration is approved, the proposals need to be prototyped. All the wiki pages will be tagged with Needs Prototype (vX.X)
. If you are implementing a prototype for a proposal, you should update the proposal's wiki page with information about your prototype and add a Prototype in progress (vX.X)
tag to the wiki source. Once your prototype is complete, and any necessary modifications to the spec have been discussed and incorporated into the current draft, the proposal page should be tagged with Has Prototype (vX.X)
.
Final review and publication
Once all proposals have been implemented and any necessary changes made to the draft specification, the community reviews the draft and conducts a final vote to promote the current draft to an official spec. At that time we'll reset this page to start focusing on the next iteration.
OpenSocial Specification Roadmap
Introduction
In the interests of release predictability and transparency, here is the roadmap for current and future OpenSocial specification development.
For each major release of OpenSocial, we will publish an Implementor's Draft where all major specification changes will be incubated until such time that the community has made significant implementations of these incubating changes and provided feedback. While there is wide agreement in principal, the Community still needs to define and vote on this new process. Once established it will be documented in the specification process.
The OpenSocial Foundation will plan for a yearly specification release cadence on the OpenSocial specification.
OpenSocial 2.5
Themes for OpenSocial 2.5
- Targeted cleanup and de-incubation of major changes introduced in OpenSocial 2.0
- Embedded Experiences
- Common Container
- Specification cleanup that does not require major editorial changes
Date |
Milestone |
---|---|
Early April 2012 |
First Draft |
June 2012 |
Final Draft |
July 2012 |
Voting |
OSCON, July 2012 |
Final |
List of Changes: Spec Changes - v2.5
OpenSocial 3.0
Themes for OpenSocial 3.0
- Full editorial review (and rewrite) of the specification
- Revamp of the OpenSocial REST API
- OpenSocial Spaces
Date |
Milestone |
---|---|
May - Sept 2012 |
Call for New Features |
May 12 - Jan 13 |
Monthly Implementer's Draft |
January 2013 |
Release Candidate 1 |
February 2013 |
Release Candidate 2 |
March 2013 |
Final |
List of Changes: Spec Changes - v3.0
Specification Proposals
OpenSocial 2.5 Proposals
Each entry should be a link to the Feature request on OpenSocial Resources.
Specification Cleanup
- Broken links in spec for app id / group id (Issue 1239,Issue 1223)
- Inconsistencies with "-ID" and "-Id" (Issue 1244)
- Person service clarification / Update API (Issue 1233)
- Align the REST core and core API specs to wrap collection response with "list" property (Issue 1230)
- Fix missing ExternalService tag in gadget schema (Issue 1224)
- Templating Spec Issues (Issue 1243)
- Duplication in makeRequest (Issue 1240) (Fix osapi.http, align request parameters (FULL_HEADERS, etc))
- Embedded Experiences Clarification (Issue 1236)
- CoreGadget/DataRequest does not link to reference of acceptable values (Issue 1227)
- Clarify language around views (Issue 1205)
- Create index of APIs -> Features (Issue 1246 )
- Versioning Refers To The Wrong Version Of The Spec
- No explanation of callback function for osapi.http methods
- Remove in-spec references to Portable Contacts (poco draft has no official standing anywhere, hasn't been updated in several years and everything it defines is largely already covered by the OS spec) (Are we still doing this? There has been discussion on the group about reviving the effort.)
- container.views.destroyElement clarification (since this is incubating, we *should* be able to do this)
Spec Changes
- Metadata service (Includes discovery) (Issue 1261)
- Common Container discussion
- newGadgetSite and newUrlSite methods (Issue 1235)
- Finalize common container spec and move it out of incubation (Issue 1248)
- Update common container GET_PREFERENCES interface to be async
- Token Refresh API
- Enhance open-views and CommonContainer APIs (is this a 2.5 item??)
- Allow openEmbeddedExperience, openGadget, and openUrl to be able to specify x,y coordinates
- Embedded Experiences Discussion
- More precision for EE data model & passing the entire model when EE is opened (Issue 1284)
- Simplify the amount of boilerplate code required to get the EE context (Issue 1249)
- Adding label on plural fields (Issue 1282)
- Additional group models: @followers/@following/@colleagues/@reports/@manager (Issue 1281)
- Add Icons/Screenshots/Privacy Policy/License to gadget metadata (Issue 1283)
- Completion of the multipart upload work (gadgets.proxiedMultipartFormPost)
- Need to complete OAuth 2.0 related stuff (e.g. Issue 1201)
Candidates for Deprecation (Issue 1275)
- Tabs
- Skins
- OpenSocial WAP Extension
OpenSocial 3.0 Proposals
This page will be used to track the proposals for OpenSocial 3.0!
Each entry should be a link to the Feature request on OpenSocial Resources.
New Proposals
- Completion of the initial Spaces proposal work (Incubate in 2.5)
- Refactor the MediaItems/Albums service and combine with the CMIS work to have a single consistent File service? (related: Issue 1174) (Incubate in 2.5)
- Revised Specification Process
- File upload (how does this relate to multi-part upload)
- Protocol and Data Format Versioning (threads: [1][2]... module versioning as well?)
- Define AppData as a Core Service (not an optional Social Service)
- Adding resources on OpenSocial objects
- Opened Issues:
- Optional, extension query string parameters.
- connectionTimeout and readTimeout Parameters?
- Make shared-script-frame a specified feature.
- Search For OpenSocial Data (see also, Persistent Query Service proposal)
- 3.0 REST API Updates
- Simplification?
- Refactorization?
- Leveraging new emerging HTTP capabilities (PATCH, Link and Prefer headers)
- Updated Person model
- Persistent Query Service REST API
- Proxy Service REST API
- Federated Social Context
- Simplified Discovery
- Microdata Mapping
- Simplify Cache Service
Spec Cleanup
- Simplification and Clarification of entire spec** Drop Core API Spec Document... merge it's stuff more intelligently into the other specifications
- Provide a new Use-Case Driven Primer
- There are many, many more issues... See here for a small sampling... (preview)
- Move container language from other specs into common container spec (Issue 1247)
Candidates for Deprecation
- Deprecate OAuth 1.0 requirements
- Can we deprecate or at least separate the RPC protocol.. perhaps isolate it for use only with the Javascript API?
- Can we deprecate the XML Format??? (must have replacement API incubating)
- Deprecate media items / albums in lieu of CMIS alignment
- Deprecate makeRequest (must have fixed osapi API incubating)