Spec Changes
From OpenSocial
Overview
Contents |
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 0.9 archive or the 1.0 archive
Current Specification Draft
Once we get stated, we'll keep "drivers" of the specification here.
Spec Process
Below is a summary of how this wiki is used in the OpenSocial spec process. For information about the spec process itself, please see the Spec Process document.
Proposed Timeline
In accordance with the OpenSocial development process, this is the timeline that is proposed for OpenSocial 1.1. Because we would like to ensure we have time for the required prototypes to "bake", we will try to plan for current iteration plus one. For this reason, you will see proposals and a plan for OpenSocial 1.1. and "1.1 Next". Further, Shindig is a crucial part of most of the implementations of OpenSocial. To this end, we believe it makes sense to include and propose a time line for Shindig as well. It is our hope that this will encourage increased involvement in both projects.
At the OpenSocial State of the Union Event we agreed on a scope and time line for OpenSocial 1.1. The section below details this plan. Emphasis will be placed on iterating over working prototypes as well as the "patches" to the specification. One thing that happened during the creation of the 1.0 version of the specification is that the last phase of this process became much more drawn out. There was still considerable design work happening in what was intended to be a review of the final specification to be published. We are taking the following steps in an attempt to avoid this:
- Prototyping of proposals should begin as early as possible. No proposal voted on without a prototype in place (ideally in the Shindig sandbox)
- Draft versions of the specification will be produced on a regular basis. Sections that have been modified will be annotated to indicate, as best as possible, the changes (e.g. include a line with the code fix number in the document)
- No code changes during final review and publication
Note: OpenSocial "1.1 Next" dates are tentative.
OpenSocial 1.1 Timeline
Overview: May 18 - November 18
- May 18 - June 23: Define Scope
- June 24 - Sept 23: Prototype proposals and vote on their specifications
- Sept 24 - Nov 11: Review full specification draft
- Nov 18: Final publication
Note: Need to circle back with Paul Linder and add Shindig schedule
Details: Prototype proposals and vote on their specifications
- June 23: SVN Opened for patches. Shindig Sandbox available (Done! Working Draft / 1.1 SVN Stream)
- July 8: Specification driver published. Approved proposals with patches included (Done! July 8 Driver SVN Tag)
- July 15: Specification driver published. Approved proposals with patches included. (No changes since 7-8)
- July 29: Specification driver published. Approved proposals with patches included. (No changes since 7-15)
- August 12: Specification driver published. Approved proposals with patches included.
- Call for review on Add support for mobile devices target to include in 8-26 driver
- August 26: Specification driver published. Approved proposals with patches included
- September 9: Specification driver published. Approved proposals with patches included
- September 23: GA Driver 1 published. Full specification review begins
- October 7: GA Driver 2 published
- October 21: GA Driver 3 published
- November 11: 1.1 published. Voting begins
- November 18: 1.1 published
OpenSocial "1.1 Next" Timeline
Overview: January 6, 2011 - June 9, 2011
- Jan 6 - Jan 27: Define Scope
- Jan 28 - May 12: Prototype proposals and vote on their specifications
- May 13 - June 9: Review full specification draft
- Nov 16: Final publication
Themes for OpenSocial 1.1
As we begin the specification process, it will be helpful for us to also agree on a larger set of themes that can help us shape and focus our collective efforts. We should use these same themes as a similar guide when thinking about how we prioritize other efforts within our community. For example, we refactored the specification in 1.0 to have a much cleaner separation of concerns, e.g. gadgets, social gadgets, and a social server. However, there was no corresponding alignment of how you might consume the code in Shindig. The POMs are there, but you still need to download the whole nine yards even if you want just the Social Server. In a way, we did this for 1.0, because we did not add any significant new capability. It's theme would have been: Stability. We've started a community efforts page that we can use to coordinate activities that we need to accomplish that might fall outside of the specification process. We'll use the same themes and target timelines to guide this work as well. For 1.1, here are three areas where we can improve the specification.
- Extending Clients
- Collaboration
- Improved Consumeability
Scope: OpenSocial 1.1
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 [[Category: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 [[Category: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 [[Category: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.
Proposals for OpenSocial 1.1: Current Status At a Glance
| Proposal under discussion. Not yet included in scope. |
| Proposal approved. Patch under development. |
| Patch under discussion |
| Patch partially submitted, still needs work |
| Patch got a -1, still under discussion |
| Patch fully committed to SVN |
| Prototype available |
| Proposal | Owner | Status | Ind. CLA | Corp. CLA |
|---|---|---|---|---|
| Incorporate Open Ajax Hub as Pub-Sub Mechanism for OpenSocial 1.next | Mark Weitzel, Han Nguyen | Voted on and approved at OpenSocial State of the Union event.
[ Prototype code] is available in Apache Shindig (trunk). Working on drafting the specification text. Code Review Specification Proposal
| Y | Y |
| Shared OAuth tokens for trusted gadgets | Randy Hudson/Mark Halverson | Voted on and approved at OpenSocial State of the Union event.
| Y | Y |
| Clarify language around OAuth in the spec | Randy/Mark Halvorson | Voted on and approved at OpenSocial State of the Union event.
http://code.google.com/p/opensocial-resources/issues/detail?id=1054 | Y | Y |
| Add support for mobile devices | Chris Laffoon / Mark Weitzel | Voted on and approved at OpenSocial State of the Union event.
The Mobile View changes for Core Gadget specification has been submitted and a prototype is available. Still waiting for the spec changes and prototype from Mixi for WAP devices optional specification.
| Y | Y |
| Add support for WAP based mobile devices | Yoichiro | This was part of the initial proposal for adding Mobil View support (above), but because it's fairly independent, we've decided to pull this out and let it develop on it's own.
| N | N |
| Gadget XSD doesn't include @specificationVersion | Randy Hudson / Mark Weitzel | See: OpenSocial Resources Specification Issue if you want to add a patch.
| Y | Y |
| Cleanup of response structure in DataPipeline spec | Chris Cole | Duplicate of "Align response format between REST and RPC". Proposed thread | ... | ... |
| Deprecate DataAttribute definition of cur outside repeaters | Chris Cole | Proposed thread | ... | ... |
| Selector Syntax in EL | Chris Cole | ... | ... | |
| Support iframe model application in gadget spec | Jacky Wang | ... | ... | |
| OSML Content blocks to eliminate need for script tags everywhere | Chris Cole | Y | Y | |
| Simple Gadget format extension | Chris Cole | Y | Y | |
| External Content blocks | Chris Cole | Y | Y | |
| OpenSocial Template Updates for v1.0 | TBD | Collecting discussions from the spec list into one place | ... | ... |
| OSAPI Updates for v1.0 | TBD | Collecting discussions from the spec list into one place | ... | ... |
| REST/RPC Updates for v1.0 | TBD | Collecting discussions from the spec list into one place | ... | ... |
Proposals for "1.1 Next": Current Status At a Glance
| Proposal under discussion. Not yet included in scope. |
| Proposal approved. Patch under development. |
| Patch under discussion |
| Patch partially submitted, still needs work |
| Patch got a -1, still under discussion |
| Patch fully committed to SVN |
| Prototype available |
| Proposal | Owner | Status | Ind. CLA | Corp. CLA |
|---|---|---|---|---|
| ACLs in OpenSocial Thread | Thomas Duebendorfer / Christoph Renner | Proposal | Y | Y |
| UserPrefs vs AppData | Mark Weitzel | No one has signed up yet so, for now, I'll throw my name in the hat. From an IBM perspective, we've been looking at a number of use cases around user prefs & app data and would like to help drive this work. | Y | Y |
| Merge/incorporate Activity Streams into OpenSocial | Chris Messina / Mark Weitzel / Eric Woods | There is a patch submitted to the SVN for the spec and the code is available in the Shindig sandbox. There are several issues with this work that we are tracking down:
| ?/Y/Y | ?/Y/Y |
| Investigate spec changes to support inline gadgets | Mark Weitzel / Rich Manalang | ...(From EOS) This is a general requirement to satisfy the performance requirements found within enterprise settings. | Y | Y |
| Add semantic information to relationships | Mark Weitzel / Inbal Ronen (IBM) / Ido Guy (IBM) | ... | Y/N/N | Y/?/? |
| ACLs in OpenSocial Thread | Thomas Duebendorfer / Christoph Renner | Proposal | Y | Y |
| Align CMIS and OpenSocial | Mark Weitzel / Eric Woods / Matt Tucker / Bill Lynch | ... | Y / Y / ? /? | Y / Y / ? /? |
| Formalize Javascript Container APIs | Mark Weitzel / Han Nguyen | ... | Y / Y / ? /? | Y / Y / ? /? |
| Add semantic information to relationships | Mark Weitzel / Inbal Ronen (IBM) / Ido Guy (IBM) | ... | Y/N/N | Y |
| Make JSON-RPC a MUST instead of a MAY | ... | ... | ||
| XSD Validation & ATOM Mapping | Mark Weitzel | We need to determine the right extension patterns for the various OpenSocial schema. Also, there was a blog post on OpenSocial's mapping to ATOM that is worth discussing. | Y | Y |
| Add additional lifecycle events and/or new management callbacks | Mark Weitzel | This could be the start of a "Management Extension" for OpenSocial | Y | Y |
| Add appInvit to OSML. | Mark Weitzel / Chris Cole | adding mobile views]. We already have the script function "requestShareApp" and
<os:PeopleSelector>. Perhaps a better approach could be to extend OSML to have a simple tag-based invite UI. <os:AppInvite /> Then the container could choose the appropriate implementation, be it a link/URL or a rich dialog. | Y | Y |
| Improvements to Tabs/Skins | Mark Weitzel | Improvements to Tabs and Skins | Y | Y |
| Action/Selection/Contribution Model | Mark Weitzel | Action Contribution Model | Y | Y |
| Embedded Experiences | Mark Weitzel / Ryan Baxter | Embedded Experiences | Y | Y |
