Configuration

[ LiB ]

Before you can deploy your first killer communication app, you need to first understand how FCS is configured. I recommend accepting all the default settings when installing the server so that the tutorials are easier to follow. In addition to deciding where the server gets installed, you have to select default port numbers , an admin name and password, and whether you plan to host files from a particular web server the installer finds on your machine. (Realize that FCS isn't a web server but rather a server that runs in conjunction with your web server.) Luckily, all the settings you make during installation can be adjusted later by editing the configuration files.

Note

Authoring Communication Apps on Macintosh

You can download and install the "authoring components" for Macintosh. However, you won't be able to run the server: It only works on Windows 2000/XP and Linux. The authoring components are just the communication components and the documentation. Authoring on the Mac involves having FCS running somewhere else. The main difference is that when your movie connects to FCS it must specify an absolute path to the server, whereas on Windows you can optionally use a relative path. Incidentally, these authoring components get installed on Windows when you install the server (provided you have already installed Flash).

Configuration Folders

A few basic concepts will help make sense of all the configuration settings. Notice adjacent to your installed version of FCS a folder called applications and one called conf. The applications folder enables you to maintain different FCS applications, and the conf folder enables you to change server configuration details. Both are discussed in more detail in the following sections.

Applications Folder

First understand that when you deliver your app, you'll still be producing SWF files hosted in HTML pages like normal. To make a SWF that connects to the FCS, however, it must point to a specific folder in the FCS's applications directory. (By default, that's inside C:\Program Files\Macromedia\Flash Communication Server MX\applications.) At an absolute minimum, you can just make an empty folder named my_app (inside the applications folder) and specify that name when connecting. The purpose of this folder is to store potentially sensitive files to which users won't have direct access, including script files (which can contain passwords), recorded video or audio streams, and shared objects (containing variables ). You make a folder inside the applications folder and only the communication server will read and write files to that foldernot web site visitors . (You're welcome to change the default applications folder location, but you should never pick a folder that web visitors can access.)

When working on a particular app, you might spread files to three places: your app folder (inside FCS's applications folder) even if it's just an empty folder; your SWFs hosted by your web server (say, within the wwwroot folder); and your source FLAs that you keep while working. Take, for example, the sample application called tutorial_sharedball. After installing FCS, you'll find both the empty folder

 C:\Program Files\Macromedia\Flash Communication Server MX\applications\ tutorial_sharedball 

and a folder full of the source file, SWF, and HTML inside your web server's wwwroot folder or, in my case, here:

 C:\Inetpub\wwwroot\flashcom\samples\tutorial_sharedball 

After you make a folder for each application, the only thing you put in that folder will be server-side scripts (covered in the next chapter) as well as prerecorded streams and MP3s (covered later this chapter). Although it may seem useless to have an empty folder, it provides FCS a place to both look for server-side scripts and write files (streams and shared objects) when necessary. (It turns out you can optionally place configuration XML files in the application directory for settings that apply to only that one application.) All this means is that for every application you make, you always want to begin by making an empty folder in the applications folder and then use that name when connecting.

Conf Folder

In addition to the applications folder, you'll find another folder adjacent to FCS called conf (short for configuration). All the configuration settings can be made through XML files contained inside conf. Although you can make many esoteric refinements, you will probably only edit a few settings here and there. Because there are several files, however, let me give you a quick rundown. (If you just want to jump right into building something, skip ahead to the section "Production Techniques" later in this chapter.)

Adaptors and Virtual Hosts

Even before understanding "adaptors" or "virtual hosts," remember that the hierarchy from the top down is server, adaptor, virtual host. Inside the server you can have several adaptors, and inside each adaptor you can have several virtual hosts (and, actually, each virtual host can have as many users as you want, too). A fresh FCS installation starts with the minimum: one virtual host (_defaultVHost_) inside the _defaultRoot_ adaptor inside the server. In a nutshell , this structure enables you to maintain multiple administrators, applications that use slightly different settings, and different web servers that all have access to your single copy of FCS. Figure 8.1 displays example hierarchy as seen through the administration console. Although you probably don't need all these options to start, the structure is built so that it's easy to expand. Think of how a new file cabinet needs to have drawers, file holders, and file folders even though you may only think you want store individual papers in it.

Figure 8.1. Besides the default adaptor and virtual host (Vhost), notice two extra adaptors (extra_a and last_one). The first has two Vhosts (with two users each), and the second has one Vhost (and one user ).

Editing Configuration Files

Exactly how to edit the configuration files and how to create a new hierarchy of adaptors and virtual hosts is detailed both in the comments contained in the XML files as well as the FCS documentation. The basic approach I take is to copy and paste entire nodes (or tags) found in the XML filesfor example, everything from <Adaptor to /Adaptor> or <VirtualHost to /VirtualHost> . As for what to change within the tags, let me detail just a few of the more common settings you may want to make.

You'll likely find a frequent need to edit Vhost.xml and Application.xml. They're inside the default virtual host (_defaultVhost_) inside the default adaptor (_defaultRoot_)as such, copies also appear in additional virtual hosts you may add. Take a look inside Vhost.xml and notice the <AppsDir> tag. Here is where the location of your applications folder (discussed earlier) is designated.

Another interesting setting in the Vhost.xml file is the <Streams> tag within the <VirtualDirectory> tag. Normally, playing a recorded stream or MP3 requires that the file reside inside the particular application folder in use. However, you can change that behavior and specify a different directory in the <Streams> tag. This means several different apps can have access to the same library of MP3 files. Defining such virtual directories involves specifying an alias (that is, the short name you'll use when playing the stream) and the actual directory where the streams reside.

Without going through all the settings inside the Application.xml file, let me point out one interesting fact: Although the main Application.xml contains settings for all the applications within a particular virtual host, any individual application can have its own Application.xml file (stored in the application's folder). The settings in such a local copy override the global settings in the main Application.xml file.

Tip

Restart the Server

The big thing to remember, and something I'll repeat for emphasis, is that for changes to take effect you must restart the server.

Production Techniques

While programming and testing FCS apps, I find myself following and often forgetting to follow a certain set of procedures. You might think this section is more appropriate as a follow-up after you get the basics. However, if there's one thing that will frustrate you to no end, it's stupid mistakes. Hopefully, the following techniques will not only save you endless hours of rework , but also serve to introduce the basic mode of operation for a communication app programmer.

Restarting

Not only will you occasionally need to restart the Flash server (after making changes to the configuration files), you'll also need to restart your individual applications. What I didn't mention earlier is that although every app has an application folder, you also can run multiple instances of any single app. The best analogy to app instances is how a single chat application can have multiple "rooms." Just like movie clips or really any object, applications have instances.

The first time a SWF connects to your app, an application instance is created. It remains in FCS's memory until you unload it, until you restart it (that is unload and then start again), or until it times out from inactivity. Even if you close all connections to FCS (that is, close the SWFs that are connected), the app instance and all application variables remain in memory until the instance unloads. Although you can always restart the entire FCS server, sometimes you only need to restart an individual app instance.

The Communication App Inspector is an invaluable tool that not only enables you to unload and restart app instances, it also contains other handy information about all apps currently running on your server. The App Inspector is available under Window, Other Panels (if installed in the WindowSWF folder) and through the HTML help files (to which you should have a link in your Start menu). To use the App Inspector, you need your admin name and password (specified at installation). Use localhost for the Host field when testing locally (as shown in Figure 8.2).

Figure 8.2. Use localhost when logging in to the App Inspector locally.

After you log in, the App Inspector lists all currently active application instances. You can select any line and either unload or click View Details for more controls (as shown in Figure 8.3).

Figure 8.3. Once logged in, you can access any active application.

The App Inspector is a pretty nice example of rich Internet application (RIA) programming itself, although it can take a bit of time to get comfortable with the interface. You can explore without much risk because critical maneuvers (such as restarting apps) include confirmation dialog boxes. Realize that when viewing details of a particular app, you can return to the previous screen by clicking Change App (effectively performing a "back" navigation).

There's also a tool called the Administration Console (accessible from the HTML help files) that is similar to the App Inspector. Here you'll find more global settings such as additional virtual hosts and adaptors. You can actually load and unload app instances here as well as restart the entire server. However, I find it more effective to launch the Stop Server and Start Server batch files. (They're accessible from the Start menu or two .bat files inside FCS's tools folder.)

Here's a summary of how you can restart elements of FCS:

• View, load, and unload individual application instances through the App Inspector (as a Flash panel in the HTML help).

• View, edit configurations, load, and unload application instances as well as the server as a whole through the Administration Console (in the HTML help).

• Perform a hard stop or start of the FCS server through two batch files (in the Start menu or two .bat files in the tools folder).

Believe me, understanding how to restart will come in handy because you'll be doing it a lot!

Revisions

One of the purposes of the application folder is to give FCS a place to store streams and shared objects related to your application. In fact, such items get stored in subfolders that match your app instance. That is, inside your application folder you may find a folder called streams, inside of which you'll find a folder called myAppInstance, which contains the actual stream. It makes perfect sense to have a way to keep things straight. It's cool, too, that you can design an application and run multiple instances simultaneously .

The reason this discussion applies to production techniques is that while testing you'll likely try many ideas that don't pan out but that do leave discarded remnants that you don't need (such as unused streams or shared objects). In addition, application instances often remain in memory (hence, the fact you'll be restarting a lot). Another technique is to start with an application instance name such as test1. Then, if you ever need to start fresh, just start using the instance name test2, and everything related to test1 will clear out of your way. Finally, when you're ready to deliver the final product, you can change to a more meaningful instance name (although, I still recommend including a version numbering system to make later changes easy).

Remote Production

A Flash movie can connect to an FCS that resides on a different machine (say, at your Internet service provider or company's main web site). This means you can test movies on one machine that connect to FCS on another. Perhaps more important is that you can also use the App Inspector and Administration Console remotely, too. During a live auction, for example, I can monitor how many people are connected as well as do some casual debugging if necessary. There are just a few tricks that are worth covering when you need to perform such remote production.

You saw earlier that you can connect to a local copy of FCS by just listing localhost for Host in the App Inspector. If your server is installed remotely, you'll have to instead use the IP address to which FCS is bound. Actually, you can use the domain or IP andto be more specificyou'll want to use the address of the adaptor. (See the HostPort setting in the Adaptor.xml file.)

Note

Using a Subdomain

When you go live, it's common (and easiest ) to have FCS on a separate IP and domain than on your web server. Usually, this is just a matter of putting FCS on a subdomain of your web site's domain. For example, my service provider (mediatemple.net) hosts my domain phillipkerman.com, but they configured the shared FCS to use something like flashcom.phillipkerman.com. Regardless of whether you register a subdomain (the part that precedes your domain name), you'll always have a static IP address you can use.

You may need to work both locally and remotely (sometimes doing tests locally before uploading files), and that means you'll need to remember several host names , admin usernames, and passwords. Although the Remember Connection Data option in the various panels is nice, it only remembers the last set of data. Because that option uses the local shared object, however, you can just create multiple copies of the panel SWFs and each copy will remember its own set of data. For example, name one app-inspector_remote.swf and one app-inspector_local.swf. (Just search the FCS program folder for admin.swf and app_inspector.swf.)

I realize you probably want to get rolling with building cool apps, but I also know tracking bugs is easier when you're not wrestling with the tools. FCS adds additional levels of troubleshooting.

[ LiB ]