#

## Chapter 7

## How Channels Work

Up until this part of the book, I've been presenting the Castanet technology primarily from the point of view of someone using the tuner or someone responsible for setting up and administering the transmitter. From this point on, we'll be looking at the Castanet technology from the other side of the process, from the point of view of the channel builder or developer. If you're interested in creating your own channels, to publish them on a Castanet Transmitter and have them subscribed to and downloaded via a Castanet Tuner, from this point on you'll get all the information to do just that.

This chapter starts with an overview of how channels work, building on the basic introduction you got in Chapter 1, "An Introduction to Castanet." In this chapter you'll learn more about the process of creating, publishing, and updating a channel, as well as information about the kinds of features you can implement in channels.

> ####

> Note

> If you've skipped through the first two parts of this book to this section, make sure you have at least a passing understanding of the various pieces of software in the Castanet suite, particularly the tuner and the transmitter.

### Channel Distribution:
From Developer to Transmitter to Tuner

You've already seen the tools that make up the core of the Castanet technology. You use Castanet Publish to publish a channel on a transmitter. The Castanet Transmitter makes that channel available on a network. And the Castanet Tuner allows users to subscribe to channels on transmitters and to manage updates to those channels. But what's actually going on here?

Castanet automatically "mirrors" the data contained in a channel—be it executable Java classes or text files or HTML—from the developer's original location to the transmitter to each individual tuner's local disk. Each time, then, that the developer makes a change, Castanet keeps track of that change and uses that information to update the data on a client tuner's system (as shown in Figure 7.1). This section explains how it all works.

Figure 7.1. Developer to Transmitter to Tuner to User.

Developer to Transmitter

As a channel developer or producer, you store your channel data somewhere on your local disk, in its own directory. Inside the channel directory are the files specific to that channel, such as Java class files, images or other media and data.

> ####

> Note

> For much of this section I'll call the person who creates a channel the channel developer. Although the term developer often refers to a programmer, it can also refer to someone creating a Web site or designing a presentation—tasks that don't necessarily involve much programming. To simplify things, however, we'll just call anyone who produces a channel a channel developer.

When your channel is ready to be published on a transmitter, you run Castanet Publish, set a few basic properties, and publish the channel. The publish tool not only puts the files on the transmitter but also keeps track of the makeup and contents of the channel itself. Part of the publishing process involves calculating checksums for each of the files in the channel and for the channel itself.

> ####

> Note

> A checksum is a numeric value that represents the file. Each time you change the file, the checksum changes as well. The checksum provides a fast and simple way to figure out if a file has changed.

With all the checksums calculated, the transmitter stores the channel files in its channel directory, and that channel is ready to be subscribed to by a tuner. Note that the version of your channel in the transmitter's channel directory is not a simple copy of your channel directory; the transmitter stores the files in a special format in its channel directory in order to optimize changes and share identical files between channels. This is one of the reasons why you have to use the publish tool to publish a channel; if you simply copied your files into the transmitter channel directory the transmitter would not know what to do with them.

To update a channel, you simply make the changes you want to make—to the channel files, to the properties, or to the parameters—and the run Castanet Publish again. This time, the publish tool keeps track of the differences between the first version and the next version, so that when a tuner requests an update the transmitter will sent back only the changes to that channel and not a whole new copy.

Note that as a channel developer you don't have to keep track of the specific changes you've made to your channel. You don't have to create patches or different files or build an updater program. Castanet Publish handles all of that for you. All you need to do is keep working and update each time you have a change that's significant enough to make available to your users.

So, for example, let's say you've create a Crossword-of-the-day channel, which lets your users play a game of crossword. (There actually is a crossword channel available at `trans.marimba.com`.) You might create the code for that channel and its data file, which contains the hints and the layout for the crossword, and publish that channel to a transmitter. Then, every day, you would change the data file to provide a new crossword and republish the channel. Castanet Publish will move only that data file to the transmitter (since its the only file that changed), and when a tuner requests and updates, that data file will be the only data that gets sent to the tuner.

Transmitter to Tuner

If you're a channel user, you see the process from the other side: The tuner "mirrors" files contained on the transmitter onto the local disk, and manages updates to those channels.

The first time you download a channel with the tuner, the tuner downloads and installs the channel from the appropriate transmitter in its entirety—with one exception. Files and libraries are shared between channels, and identical files are downloaded only once. So, for example, let's say there's a special Java class library for handling secure network connections called `SSL.zip`. The first time the tuner downloads a channel that requires that library, `SSL.zip` is downloaded and installed with that channel. Then, if there's a second channel that also uses that same library, the tuner checks to make sure it is precisely the same file (using the file's checksum, which the transmitter sends with each file), and the second channel simply uses the first channel's version rather than re-downloading the same library all over again.

As with the storage of channel files on the transmitter, the tuner stores the channel files on your local disk in its special optimized format, to keep track of which files need changing and which files can be shared.

For each update, the tuner contacts the transmitter, and the two negotiate which files the tuner needs to download. The update process starts with what's called an optimized update; the tuner sends a checksum of the entire channel to the transmitter, and if it matches with the checksum the transmitter has, there isn't an update to be made, and the process is done. Because the channel checksum is small, the tuner and the transmitter can figure this out with barely a dent in the in network bandwidth.

If the two channel checksums are different, the tuner and transmitter have to compare each file to see which files the tuner needs to bring the channel up to date. This negotiation process means that only the files that have actually changed are downloaded, and even then, often only the actual differences between the two versions of the files are downloaded.

> ####

> Note

> Keep in mind that for each update, the tuner polls the transmitter for new information. Unlike Internet broadcasting technologies, Castanet is not technically a "push" mechanism. It's more of a repetitive pull. And, because the frequency of updates can be configured on the tuner side, there isn't the problem of too much unwanted data being sent over a network the way there is with Internet broadcasting.

So, for example, let's look at that Crossword channel again. The first time the tuner downloads the Crossword channel, it receives all the files for that channel—all its code plus the current data for the day's game. When it's time for an update, usually the only file that has changed is the data file—and the tuner and transmitter can quickly figure that out by comparing their checksums. Only the data file is sent to the tuner. All the other files are the same, so the tuner doesn't need to download another copy of those files.

With both initial subscriptions and updates, a channel's data is downloaded in one single transaction, with only one network connection, regardless of the number of files in the subscription or the update. This is a significant advantage over the traditional applet model, where each file is downloaded in a separate network connection. Each connection takes a few seconds to start up, and for applets with a large number of files, that can mean significant overhead just for the connections. Channels do not have that overhead.

File negotiation, downloading only the differences in files, and the use of a single network connection minimize the amount of information and the time it takes to successfully update a channel.

Live Updates

Updates can be made at any time, regardless of whether or not the channel is currently running on the user's system. If the channel is indeed running, new data received via the update can be incorporated into the channel on the fly. It's up to you, the developer, to decide how to manage an update to a channel. For running channels, for example, you could do the following:

- Incorporate the data quietly into the channel without the user noticing.
- Stop and reload the channel to take advantage of the update.
- Alert the user that an update has occurred and give the user a choice of what she wants to do with it.
- Update the channel on the fly to reflect the new data.

If the channel isn't running, the channel developer can choose to start the channel running when new data appears, or otherwise alert the user to the new update (or, of course, just ignore it until the next time the channel starts up). You have a wide range of options as a channel developer for how you want to handle live updates to a channel. You'll learn all about managing live updates to channels in Chapter 10, "Managing Updates and User Information."

### Channel Security

The issues behind channel security are similar to that of applet security: If you can instantly download and run programs (applets or channels) from random sites all over the Internet, how can you be certain that those programs will not do malicious things to your system or somehow compromise the security of that system?

The short answer is that you can't be certain. But the system can make it more difficult for the most obvious attacks or compromises to take place.

Castanet uses and builds on Java's applet security model, which has been used by Web browsers all over the world without major incident. This means that Castanet channels are restricted in their behavior in several ways:

- They cannot run programs or libraries on the local system, unless those libraries (DLLs) have been pre-installed by hand in a special tuner directory.
- They can only make network connections to the transmitter where the channel came from.
- They cannot read, write, or delete files on the local system except inside one specific directory for that purpose.

> ####

> Note

> Different browsers might implement different portions of this security model or allow parts of it, but those are the basic rules for how the applet basic security model works.

There are two specific cases where channels differ from applets: the capability to use local libraries and the capability to write files to the local disk.

In the former case, channels can use local libraries only if that library has been installed into a special directory on the local system, and the user takes all responsibility for the security and trustworthiness of those local libraries. This mechanism is called tuner extensions, and is described in Appendix C.

The second difference is the ability to save state. Applets cannot read or write to the local system whatsoever. Whereas this is a valuable assumption to make for security reasons (because it prevents an applet from discovering private information or from maliciously changing or deleting files on the user's system), it is also very restrictive for the kinds of features you can include with an applet. Applets, for example, cannot save state on the local system, nor can they save any files that the user may have created inside that applet. The only way to save state inside an applet is to log the information back to the Web server, which uses space and resources on the server. This is not an optimal solution.

With channels, state can be saved and restored to and from the channel's data directory on the client, but only to and from this directory. This allows the channel to save necessary files and information while preventing it from doing damage to other parts of the file system. You'll learn about saving state in channels in Chapter 11, "Managing Updates and User Information."

With permission, channels can also read files from a CD-ROM contained on the local system. So, for example, you could publish a multimedia channel that makes extensive use of really large image files stored on a CD-ROM, to prevent having to download those files over the network. To read files from a CD-ROM, the user will have to configure that option in his or her tuner.

> ####

> Note

> The restriction on applets to be able to write to the local file system is one that has been imposed by Web browsers. Both Netscape and Microsoft are planning to ease that restriction in future versions of their browsers (which might be out by the time you read this), allowing the user to decide how much access an applet will have to the client's system—including potentially allowing it to write to the user's hard drive. Despite this easing of restrictions, however, applets may or may not be allowed more freedom depending on how the browser is set up. Channels will always have a data directory, and you can rely on the existence of that directory in the channels you create.

Because executable channels are written in Java, they also inherit Java's built-in security and safety: For example, the lack of explicit pointers in Java means fewer bugs or exploitable security holes in a channel. And, given Java's model for security and consistency checking, it's difficult if not impossible for a malicious individual to try to work around the restrictions in the Java environment.

Future versions of Castanet will include even more sophisticated mechanisms for channel security and access control, including the ability to create password-protected channels (you must have the password to be able to use the channel, not just to publish it), channels that can run over secure network connections, channels that are digitally signed (providing a guarantee that they come from a specific vendor and have not been modified), as well as billing mechanisms for channels and for updates. These mechanisms will also allow channels to be written in other languages, and for Castanet to become a mechanism for the delivery of any kind of software or data, not just Java and HTML-based software and data.

Transmitter Plug-ins and Channel Feedback

The transfer of a channel's information works, for the most part, in one direction: A channel migrates from the developer through the transmitter and the tuner to the user's system. This does not mean, however, that channel developers can never get data back from the people using their channels. There's a feature of the Castanet technology called the transmitter plug-in, which lets channel developers get data back from their users and handle that data in a variety of ways.

A transmitter plug-in is a bit of software that is part of your channel: You include it in your channel directory, and it gets published to the transmitter just as the normal channel data does each time you run Castanet Publish. Unlike the regular channel, however, the plug-in is not part of the data that is sent to the tuner; instead it remains on the transmitter and runs when a tuner makes a request for new data from a transmitter.

> ####

> Note

> The term plug-in might be confusing if you're used to associating the term with Netscape or Photoshop. Transmitter plug-ins are not installed into a special directory in your transmitter, nor do they simply extend the features of that transmitter. They behave more like filters for channel data. Read on for more information.

Transmitter plug-ins are useful for two purposes: channel logging and channel customization.

Logging

Channel logging is the ability to store information about what the user is doing with the channel and then receive and process that data when the tuner requests an update from a channel. The channel itself can be designed to store data about what the user is up to—sites they might have visited as part of a channel, scores they made on a game, or any other information that the channel might be interested in. Then, when the user makes an update, the transmitter plug-in is run and that logging information can be read and processed by the plug-in. You can do anything with that information you want; simply write it to a logging file to be processed at some other time, generate statistics on that data, or perhaps update a global list of high scores, which is then downloaded as part of the channel's update.

> ####

> Note

> You can log data from inside you channel even if you don't use a plug-in. If there's no plug-in to handle log entries, that data is written to the channel log files stored in the transmitter's channel directory.

In many applets, this process is managed by running a program on the Web server where the applet comes from, and then making a network connection from the applet back to that server. Data can then be sent as often as the applet needs to send it. Whereas the transmitter plug-in form of logging accomplishes a similar process, it has several advantages:

- There is no live network connection to hog resources between the tuner and the transmitter. The connection is made to the transmitter as part of a regular update, stored data is uploaded to the plug-in, and the connection is closed.
- Because the transmitter plug-in doesn't require a live connection at all times, this allows channels to be run without a network connection while still collecting and storing information that might be interesting to the channel developer.
- Unlike with applets, the tuner managing a channel can be uniquely identified across updates and sessions. Although personal user information such as a name or an e-mail address isn't available, each tuner has a unique identifier that can be used to track that tuner's behavior across sessions. This is a significant advantage over the Web model where user tracking is extremely difficult.

Channel Customization

Whereas with channel logging the result is to simply keep track of data, channel customization determines which files are sent to the tuner as part of the update, often based on the information the tuner sent in the first place.

For example, the channel could store a set of user preferences as part of the channel's state, in which one of those preferences is language (English, French, German, and so on). The preferences are sent to the transmitter plug-in as part of an update, and the plug-in can process the preferences for the language and then send user interface elements back to the tuner in that appropriate language. Or, for example, in a multilevel game, the channel can keep track of a user's progress through the game and only update the channel to the next level when the user has reached a certain point in the game. With plug-ins this can happen quickly and automatically, to reduce the amount of data sent over the Net at any one time or to provide a custom experience for the user.

You can also use features of channel customizations to dynamically generate files with every update—for example, to extract data from a database and send that data to the tuner automatically.

You'll learn more about transmitter plug-ins in Chapter 12, "Creating Transmitter Plug-ins."

### Types of Channels

As a channel developer, you have several different choices of the channels you can currently create, depending on your situation and how many resources you have to devote to the task. Each different kind of channel provides different features for the user and different capabilities for the developer. You'll learn how to create each of these channels in the chapters further along in this book; this section summarizes the types of channels, their features, and the advantages of using them.

The four kinds of channels you can currently create in Castanet are

- HTML channels
- Applet channels, written in Java
- Presentation channels, written in Castanet's Bongo
- Application channels, written in Java

> ####

> Note

> In the current release of Castanet, you can create executable channels (programs) using the Java language only. Using Java guarantees security and safety for the code that a tuner downloads, as well as providing all the cross-platform features of Java (that is, the ability for a single Java-based channel to run equally well on multiple systems). Future versions of Castanet will allow channels written in other languages and compiled for specific platforms.

HTML Channels

One of the simplest forms of channels you can create for Castanet is the HTML channel, which consists of the usual files you'd find on a Web site: HTML pages, images, media, Java applets. Nearly anything you put on a Web site can be included in an HTML channel.

HTML channels are subscribed to using the tuner in the same way that you subscribe to a regular channel. When you launch an HTML channel, the tuner acts as a proxy between a Web browser and the HTML content. (You'll have to specially configure your browser to work with the HTML channel. Chapter 3, "Using the Castanet Tuner," described all this in detail.)

Why bother with an HTML channel? Isn't a Web site just fine the way it is? In many cases, yes, the Web site model works just fine. But publishing a Web site as a channel as well offers several advantages:

- As a channel, a Web site becomes persistent on the reader's disk, and downloaded in the background. This means that each time you visit the Web site, you don't have to wait for each page and image to download. And, because HTML channels update the same way regular channels do—incrementally, in the background—you still get the newest version of the channel each time you visit it.
- You don't need a live Internet connection all the time to browse the Web site. You could, for example, subscribe to a Web site as a channel from a laptop and then take the laptop on a long plane trip. Because the Web site is a channel, you'd still have access to the information on that Web site without needing to be connected to the Web all the time.

Also keep in mind that you can publish the content of an HTML channel both as a regular Web site and as a channel simultaneously, and neither one will interfere with the other. Your readers can browse the site either as a channel or as a regular Web site as they so choose. Set up the publish tool to update the channel side on a regular basis, and you don't even have to worry about it on the development side. You can concentrate on developing and updating the Web site as usual and let the publish tool take care of the rest.

You'll learn how to convert a Web site into an HTML channel in the next chapter, "Building Simple Channels."

Applet Channels

The second-easiest channel to create is an applet channel. Applets are Java programs written specifically to run inside a Web page on a Java-enabled browser. Converting an applet into a channel requires only a few simple steps, and most applets will run as easily as channels as they do embedded in Web pages without any modifications to the Java code.

Applet channels, when run as channels, run in their own windows on the desktop, rather than being constrained inside a Web page and a browser. Other than that, however, they have the same restrictions and limitations as applets inside Web pages do. Applet channels are most useful for porting existing Java code to a Castanet channel quickly and easily.

Because channels can publish applets nearly as-is, you could create a single applet and use the same class both as a channel and as an element of a Web page. Readers visiting the Web page your applet is on would download and run the applet in the usual way; users of Castanet would subscribe to the applet as if it were a channel. If you change the applet, readers of the Web page would get the changes the next time they visit that page; subscribers to the applet channel would get the changes as an update through the tuner.

Applet channels can also be modified to take advantage of tuner functionality and to include advanced channel features such as the capability to save state on the local system, or to log channel data to a transmitter plug-in. However, applets modified in this way usually cannot run outside of the channel mechanism because of their reliance on channel features.

You'll learn more about converting applets into channels in the next chapter, "Building Simple Channels."

Presentation Channels

A presentation is a special term that refers to user interfaces and simple applications built using Marimba's Bongo program. You can use Bongo to build the user interface or the look of an application or a channel, much in the same way you would use an interface builder for other languages or environments: by creating and arranging various user-interface widgets on a screen using mouse clicks and drags as opposed to writing laborious amounts of user-interface code by hand. Bongo provides a simple interface for creating user interfaces that requires no programming; you can also add actions and interactivity using Bongo's Java-based scripting language.

Presentations created by Bongo can be used as channels. A very simple presentation channel, for example, might have a message of the day or display news headlines. Updates to the channel would be the message or the headline to be displayed.

You can also use presentations as the basis for building full-fledged Java applications. Use Bongo to create the interface, and then add functionality either through Bongo's built-in scripting or just use the presentation file as the front-end for a complete Java application. Bongo's ease of use both in assembling and managing a user interface can make it an excellent alternative to using Java's own AWT.

You'll learn more about creating presentations with Bongo in Chapter 9, "Creating Presentations and Channels Using Bongo." For a more complete description of Bongo, you'll want to pick up Official Marimba Guide to Bongo, also published by Sams.net.

Application Channels

At the high end of channel development is the application channel. Application channels require the most amount of Java programming in comparison to other channels, but they can also take full advantage of all Castanet's features, including dynamic updates to both active and inactive channels and the ability to save state on the user's local system. Application channels can also use transmitter plug-ins, for the ability to receive data back from a user's system and to customize a channel based on that data.

Applications are essentially regular Java programs. They can be written entirely with standard Sun JDK classes, or they can use presentations created with Bongo as their user interface (or both). What makes an application channel a channel is code to implement the channel interfaces and to react to channel events. You can add this code to existing Java programs (or to applets, for that matter), or you can create a channel entirely from scratch.

Note that application channels are not automatically converted Java applications, as are applet channels. There is no magic wrapper that will allow a regular Java application to run as an application channel. If you want to convert a regular Java application into a channel, you have to add code to implement channel behavior. Also, keep in mind that channels have a similar security model to applets, which means that there are more restrictions on what an application channel can do than there are on regular Java applications.

You'll learn more about creating application channels in Chapter 10, "Developing Channels from Scratch."

### Channel Ideas

Even with a basic understanding of how a technology works, sometimes it is difficult to figure out what it's good for—that is, the practical applications you can create with that technology. Here, then, are some ideas for the sorts of things you could create with channels and with the Castanet technology:

- Conventional applications, from browsers to spreadsheets to games. Not a very interesting use of the technology but, nonetheless, very valuable for both the developer and the user because of the lack of an install process and the automatic upgrades. Conventional applications delivered as channels can be distributed faster and in smaller increments, allowing bug fixes and new features to be released and deployed faster. On the user side, channels allow you to avoid the need to keep installing upgrades or to wonder whether the version you have is the latest version.
- News, sports scores, or stock channels. Because channels can be updated at regular intervals, applications that rely on frequently updated data can work exceptionally well as channels. A headlines channel could display current headlines. Stock channels could display running graphs of current stock prices, and sports-score channels would update as the game progresses. And, because of transmitter plug-ins that allow channel feedback, the data that is displayed on the channel can be personalized to reduce download time and to provide a much more interesting application for the user.
- Thing of the Day channels. Similarly to the news channels, a Thing of the Day channel could provide a new version of an application every day—for example, a Dilbert Cartoon of the Day or a Crossword of the Day. Thing of the Day channels provide a new experience for as long as you have the inclination to keep updating the data.
- "Disconnected" database clients. Because a channel can store data and send it back to the transmitter as part of an update, channels can be created for client-server applications that would normally require a live connection back to a server. For example, take an order-entry system for, say, furniture. Given a traditional client-server order-entry system, the sales person would enter the values into a form and then transmit the order to a database via a live network connection. Using the channel version, the sales person could accumulate multiple forms and then transmit them all as part of an update. This could be useful for field sales where the order-entry system is part of a laptop. Update the channel before leaving on the sales call with the latest form interface and price list (sort of like charging your hard drive, the same way you charge the batteries on the laptop), enter in the orders on the sales call, and then transmit the final orders when the sales person is back in the office and has a network connection again.
- Media-heavy applications or games. Currently, many games and multimedia presentations on the Web are hampered by the large size of the media. Because channels can incrementally download pieces of data based on user preferences or state, a game or multimedia presentation could be distributed in parts. When you're finished with one level or section in the game, an update would download the next section. And, because the fields are stored on the user's system in between downloads, you could set the game to update overnight or during an idle period and have it all ready to play when it's time.
- Computer-based training. In a similar scenario to that of the incremental games, a computer-based training course could start out at the first section with the initial subscription, and only allow users to continue to the next section (that is, to retrieve the next update) if they have completed the first section. Because each section is incrementally downloaded, only the sections that users have progressed to are stored on the users' systems, rather than the entire training application.

### Summary

In this chapter you got your first peek under the hood of how Castanet and channels work together, and you got a basic overview of the sorts of capabilities available to you as a channel developer. Depending on your background and how technical you want to get, you can create very simple channels that change very little from update to update—or go whole hog and develop very sophisticated channels that rely on frequently changing data, live updates, and feedback data to customize the version of a channel the user sees. From this point on, we'll be working with actual channels and you'll get a feel for the different kinds of channels and capabilities Castanet offers you.