[Editor's Note: This was originally posted on the Embedded Master] 

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:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

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.

Tags: Sandbox Principle

This entry was posted on Monday, April 12th, 2010 at 12:00 pm and is filed under Robust Design. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.