THE COMPLETE TECHNICAL PAPER PROCEEDINGS FROM: “BUT THE DEMO LOOKED GREAT” A TECHNICAL PRIMER ON SETTOP SOFTWARE DEVELOPEMENT Stephen Johnson Coach Media Abstract this knowledge, cable operators and other gatekeepers can ask the right questions and Creating effectively designed software— thereby create—or procure—better for any platform—is a complicated and time- applications to meet their ever-expanding consuming business. Creating software for needs. digital settops has encountered challenges unique to the cable industry: scarce MIDDLEWARE: FLEXIBILITY VS. applicable design precedence, a thankfully SPEED temporary mania of inflated expectations for “interactive television,” and a paucity of Middleware refers to a software basic technical knowledge about how application that runs programs—but also runs applications are created and deployed. While on top of an existing operating system (OS). the first two issues have largely faded, the Think of a web browser, e.g., Internet last continues to hamper effective application Explorer™ running “on top of” Windows™ deployment. Without a general and you get the idea. A middleware understanding of the issues involved in settop application uses code—or even just files of software design, cable operators will text or formatted data—written according to inevitably experience frustration and disap its own languages and syntax rather than that pointment with their deployments. of the OS. The diagram below illustrates This paper addresses five topics in how these various applications stack up: software design applicable to digital settops, SETTOP SOFTWARE STACK providing a brief technical background of DATA & GRAPHICS each issue followed by their individual effects on software performance—and ultimately MIDDLEWARE APPLICATION(S) viewer comprehension and acceptance. DATA & GRAPHICS While illustrated by real-world examples, MIDDLEWARE NATIVE this discussion does not focus on a particular APPLICATION(S) settop box manufacturer or set of features; OPERATING SYSTEM rather, the principles discussed here apply to all platforms. The topics cover the following: Schematic diagram of typical digital settop box • Middleware Usage software stack • Memory Allocation Current Examples • Settop Performance • Viewer Interface Details How and where is middleware used? The • TV Display Technology most prominent use today is probably the OpenCable™ Application Platform (OCAP), While not comprehensive, this list which uses middleware called the Java nevertheless covers a range of technical Virtual Machine™ (JVM). Java™ was issues collectively having a large impact on originally developed by Sun Microsystems as successful software deployment. Armed with an Internet-friendly programming language that could execute code using a JVM on any faster. Sometimes much faster. The reasons operating system. OCAP applications, for this are simple: fewer instructions to therefore, are written in Java and could translate and direct, customized code. Think potentially run on any settop operating of the stack diagram above; when a system; the JVM would handle all the middleware program runs its code it has to be underlying operating system routines. continually translated for the operating system. The difference is as dramatic as While OCAP remains the most prominent speaking English to an English speaker middleware example, the settop box versus speaking Italian to the same speaker development world has also seen the and attempting to translate it in real-time. introduction of middleware applications from While the translation will generally work, no companies like OpenTV, Liberate, and one can reasonably argue it will be as fast or Microsoft. With so many companies offering as clear. middleware solutions to settop development, why consider any competing strategy? While it’s certainly the most important Indeed, in addition to the promise of OCAP reason to avoid middleware development, middleware offers some very tempting lack of speed alone unfortunately doesn’t advantages. exhaust the disadvantages. Middleware is also very large. Since it translates The Best of All Worlds? instructions for many different operating systems—and needs to be resident in the Start with labor. Given the latent settop’s memory to execute commands at popularity of Internet-based programming a anything approaching reasonable speed—by relatively large pool of trained candidates has necessity it often requires generous amounts become available to code middleware of precious memory. Many middleware applications—at least of the browser-based applications simply cannot run on older or JVM variety. Since middleware digital boxes due to memory restrictions. programmers don’t write code directly to the operating system, developers are additionally In addition to its other difficulties, free to “script” quick applications and test middleware platforms also aren’t—alas—as them without enduring the rigor of compiling flexible as advertised. Even Sun’s touted and linking code. Think of an HTML Java, once marketed as “write once, run scripter doing a quick web page layout anywhere” has occasionally been derided as compared to a C++ programmer writing “write once, debug everywhere.” Even proprietary code and you can appreciate this discounting the jokes, Java developers often difference. find they have to adapt code for JVMs to their particular use. With deployment flexibility and an available labor pool on its side, what So use of middleware—a key decision disadvantages could there be to middleware point in settop software development—really development? Why suffer through hiring comes down to flexibility versus speed, with programmers to work in a very specific and a sizeable caveat on the former and little unforgiving development environment—on argument over the latter. code that can’t be used elsewhere? In a word: speed. Programs written without middleware overhead simply run MEMORY: BE LEAN, MEAN, AND PLAY Developers recognize these issues and WELL WITH OTHERS devise appropriate strategies to save memory space, but the resulting tradeoffs are far from Whether an application uses a middleware painless. Memory-related challenges platform or not (see previous section), it still confronting developers—along with loads into the settop’s memory when accompanying strategies and tradeoffs—are launched—not unlike how a program loads noted in the table below: on your PC. Compared to an average PC, however, settop memory is severely limited. Challenge Strategy Tradeoff(s) Large application • Store unused • Interactive The first issue confronting application size (including components performance memory usage, therefore, is simple: how supporting data) on server when much room do you need? Many developers vs. limited • Distinguish uploading memory between new data equivocate on this issue—and not without launch-ready good reason. The raw code size specified for and full an executable application may be misleading application for at least three (3) reasons: Large application • Store unused • Interactive graphics vs. components performance • The additional data the application limited memory on server when requires (e.g., program guide data) might • Compress uploading graphics new graphics be even larger than the code that • Use settop- • Graphic manipulates it; based degradation • Graphics and other large non-code graphics • Customized graphic components might not be included (for programmin good reason) in an application’s memory g footprint; and Multiple • Limit • Application • An application may be sharing memory applications number of Swapping space with several other applications— residing in simultaneous • Extensive about which it has no knowledge—and memory running Quality applications Assurance might be unstable at any size. • Certify (QA) deployed Why do developers need to address these applications issues? Program guide data, for example, can be enormous. One day of TV listing data To save memory many developers keep a uses up to 250 kilobytes of memory. Doing subset of application code, data, and/or the math it’s not hard to see why loading two graphics stored on a remote server and only weeks of guide data (14 x 250K, or 3.5 load it when required (e.g., on viewer megabytes) into settops with free memory request) to do so. While this strategy saves sizes of a few megabytes presents some space, the process of swapping in code and difficulties. Graphics are arguable worse: data might create some awkward one high-resolution (uncompressed) full performance delays when contacting a screen background requires almost a remote server. Delays become acutely painful megabyte of data. And lack of vigilance when loading graphics as viewers wait for an about several different applications interface to “arrive” and a screen is not yet (regardless of size) residing in memory has visually “complete.” very high costs: settop crashes (and reboots) correlate very well with this situation. A related memory-saving strategy a settop’s memory creates challenges of its effectively divides an application into parts, own. Furthermore, these challenges directly allowing a smaller version to launch (e.g., affect the cable operator since individual initially display on-screen) while the full developers may have no prior knowledge of version is stored remotely (e.g., on a server, other applications with which their programs as described above) and downloaded later. need to co-exist. While requiring some programming subtlety, this strategy mitigates performance delays As noted above,