Extensions
From OpenSocial
Contents |
Motivations
- Enable wide adoption of OpenSocial without imposing unnecessary requirements. Different containers have different needs, so a one-size-fits-all approach is not going to work.
- Allow niche-features while avoiding anarchy. Whenever multiple containers have a common need, the implementations should be compatible.
- Allow new features to mature at their own pace. OpenSocial's iteration process should not slow down development of a new feature.
- Use the OpenSocial spec iteration to validate prototypes, not implement them. Extensions will already have implementations by the time they're proposed to be added, so the spec process can focus on validating the design of the extension, the completeness of the implementation, and issues related to integrating the extension with the rest of OpenSocial.
- Have more predictable spec timelines. Taking software development out of the spec process will lead to more stable spec release cycles. In turn, extension developers will know when they need to have their extensions prepped for integration w/ the core spec.
- Keep the core spec small. The less there is to document in the core spec, the more likely we are to have compatible implementations
- Communicate the level of maturity to container and app developers. Someone interested in using a particular capability needs to know if the API is likely to change.
What is an extension?
Abstractly, an extension is some capability that an OpenSocial stakeholder (container or app developer) desires that is not in the specification already.
Concretely, an extension is defined in a document, called an OpenSocial Enhancement (OE), with language and formatting that could be incorporated into the spec. As the extension develops, it will also need a publicly available implementation and portable tests. Extensions must be defined in a manner that is consistent with the programming model currently defined in the specification.
Note: The lifecycle of an OE should be independent of the specification process. It belongs to the development process.
OpenSocial Enhancements can have the following states:
- DRAFT - the initial state. Anyone can create a DRAFT OpenSocial Enhancement.
- INCUBATING - incubating extensions may be adopted by containers, but should be treated as experimental features. The requirements for graduating from DRAFT to INCUBATING state are:
- a document specifying the capability in language and format that can be incorporated into the OpenSocial spec.
- a publicly available implementation
- a set of tests that can be run against another implementations
- a vote on the spec list (5 +1's, no -1's, and open for 5 days)
- n.b. this vote is not confined to the normal spec iteration process and can happen at any time.
- ACCEPTED - graduation from INCUBATING status...
- can only happen during the normal spec iteration.
- indicates that the interfaces and implementations have stabilized and developers can use the new capability and expect that their code will not need to change.
- may lead to the OE becoming part of the core spec
Life of an extension
How are new versions of an extension handled?
New versions must go through the same vetting process as new OEs. For example, suppose the OE for PubSub 1.5 has reached ACCEPTED status, and the PubSub community wants to work on PubSub 1.6. They need to create an DRAFT OE for PubSub 1.6 and go through the steps to graduate to INCUBATING and ACCEPTED status.
Each version of OpenSocial will list specific versions of ACCEPTED extensions than must be supported. For example, suppose that OpenSocial 1.4 defines that it supports PubSub 1.5. A container that is OpenSocial 1.4 compliance MUST support PubSub 1.5, but MAY also support PubSub 1.6 (or any other version of the PubSub OE)
How does this affect the spec?
- Verbiage in the Compliance section that links to an Extensions doc which that lists ACCEPTED extensions
- INCUBATING extensions will be listed on a wiki page and linked to from www.opensocial.org/specs
How does this affect the spec process?
The spec process remains largely the same. Proposals are not limited to adopting extensions, but larger feature sets will need to go through the extension process first. That is, you may still proposed that we change a MAY to MUST or add a function, but larger changes should be treated as extensions and iterate outside the spec process. This should alleviate some of the protoyping (and prototype ownership) issues that we saw in the last iteration
What is required of an Extension
Extensions are a way for the OpenSocial community to define new capability in a manner that is consistent with the specification. In order to accomplish this, extensions must meet the following conditions: (these need to be expanded, clarified, and more importantly, discussed in the community. this just captures the general idea)
- An extension MUST be follow the same "Notations and Conventions" as defined by the core specification
- An extension MUST adhere to the same API compatibility guidelines as defined by the core specification (e.g. no API "breakage between 'point' versions, e.g. 1.0.1 and 1.0.2")
- An extension MUST declare its compatibility with the core specification
- An extension MUST declare what other extensions (and version?) it requires for complete and proper definition and implementation
- An extension MUST NOT be required (avoid 'forcing' someone to implement an extension).... Does this make sense???
