Robust Design: Sandbox Principle - Playing Nicely
I originally planned this post to be about the “Patch-It” principle of robust design. But, I am accelerating the “play nicely” sandbox principle to this post to use the change in Apple’s iPhone Developer Program License Agreement for the iPhone OS 4 SDK, section 3.3.1 as a timely example of an approach of how to get third party software to play nicely together on the same system. Texas Instruments’ xDAIS (eXpressDSP Algorithm Interoperability Standard) is the other example we will use to explore the “play nicely” sandbox principle.
The play nicely sandbox principle is most relevant in any system with multiple components that share system resources between them. Even systems that provide completely dedicated resources, such as memory and peripherals, to each component may still share timing and interrupt processing. If the components in a system are built without any consideration to how to play nicely with other components, there are risks that one component can trash another component’s resources and cause erroneous system behavior.
Memory management and protection units are hardware resources that are available on some processors that can allow an RTOS or operating system that is managing them to protect different software components from trashing each other. Policy constraints, through standards, coding guidelines, and APIs (application programming interfaces) are another approach to enforcing the “play nicely” design principles.
Texas Instruments introduced the standard that has evolved into xDAIS and xDM (eXpressDSP Digital Media) in 1999. These standards help developers to specify and build multifunction DSP-based applications that integrate algorithms from multiple sources into a single system. A key goal of the standards is to significantly reduce the integration time for developers by enabling them to avoid selecting algorithm implementations that can trash each other’s resources.
The standards specify a set of coding conventions and APIs with the intention of eliminating integration problems caused when algorithms implement hard-coded access to system resources that are shared with other components in the system. The xDM standard also enables developers to change an algorithm implementation to a different source when a change in functionality or performance is needed. In addition to the resource sharing interfaces, xDAIS also specifies 46 "common sense" coding guidelines that algorithms must implement, such as being reentrant or avoiding C programming techniques that are prone to introducing errors.
These types of standards benefit the entire development supply chain. Texas Instruments processor architects can better justify building in components that support the standards. Third party algorithm providers have a standardized way to describe the resources that their implementation needs. This makes it easier for developers and system integrators to compare algorithm implementations from multiple sources.
The recent change in Apple’s iPhone Developer Program License Agreement represents a refinement of a similar policy constraint approach to enforce playing nicely together. The entire text of section 3.3.1 of the iPhone Developer Program License Agreement prior to the iPhone OS 4 SDK reads as:
3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.
The new wording for section 3.3.1 of the iPhone Developer Program License Agreement that developers must agree to before downloading the 4.0 SDK beta reads as:
There have been a number of discussions about the change. John Gruber closes his insightful comments about the change with “My opinion is that iPhone users will be well-served by this rule. The App Store is not lacking for quantity of titles.” In an email conversation, Greg Slepak said to Steve Jobs “I don’t think Apple has much to gain with 3.3.1, quite the opposite actually.” Steve’s reply was “We’ve been there before, and intermediate layers between the platform and the developer ultimately produces sub-standard apps and hinders the progress of the platform.”
The reason why I bring up the Apple change in this post is that, ignoring all of the business posturing hype, it is a consistent and explicit clarification on how Apple plans to enforce the play nicely principle on their platform. It is analogous to Texas Instruments’ xDAIS standard except that Apple makes it clear that non-compliance is prohibited whereas complying with the xDAIS standard is not a requirement for using or providing an algorithm implementation.
I suspect it is essential that Apple have an explicit and enforceable play nicely mechanism in place to implement their vision of multitasking on the iPhone and iPad. I hope to be able to expand on this topic in the next sandbox posting after posting about the other types of robust design principles.
To make following this series easier (especially as multiple series overlap each other), I am including the index below to previous posts. I encourage you to read all of the posts for the robust design series; maybe they will inspire you to share your observations. I would love to be able to consolidate different perspectives and lessons learned with regards to robust design practices here. I suspect there are some valuable lessons to be gleaned from comparing such stories. If you would like to participate in a guest post, please contact me.
Previous post in the Robust Design series:
2010, April 5: Robust Design: Sandbox Principle
2010, March 29: Robust Design: Fault Tolerance
2010, March 22: Robust Design: Ambiguity and Uncertainty
2010, March 15: Robust Design: Best Guesses
2010, February 10: Robust Design : Good, Fast, Cheap – pick two
2010, February 4: Robust Design
Currently no items