XML.com: XML From the Inside Out
oreilly.comSafari Bookshelf.Conferences.


Scripting Collaborative Applications with Flash Communication Server MX

Scripting Collaborative Applications with Flash Communication Server MX

August 02, 2002

When Macromedia's new Flash Communication Server MX hit the streets last month, its streaming media features were the focus of attention, and rightly so. Injecting a Webcam widget into a Flash application--one that you can share with anyone else who hits the Web page that embeds that Flash app--takes literally a few seconds and no lines of code. With a bit of server-side scripting, video feeds can be captured and played back on demand.

As David Doull said in his Thinking in Flash Weblog, "video and audio chatting is something different," as is the asynchronous audio/video messaging this technology enables. By way of example, Doull points to Dream Domain, where you can pilot an insect drone (which, if you like, you can genetically mutate) through a landscape of virtual rooms, each dotted with text and Webcam messages dropped by visitors.

Of course, for the white male hackers who mainly visit the site, the video messages found there are, predictably, glimpses into the mirror: white male hackers smoking cigarettes, pretending to be attacked by aliens, pressing eyeballs close to the lens. Still, as bandwidth grows and AV-equipped PCs become the rule rather than the exception, there is no question that audio and video will augment text as first-class datatypes, routinely created, exchanged, and used by everyone. At first this will mean more silly home movie-lets. Eventually, however, we'll learn how to use AV clips appropriately, to enhance business and social communication. When we look back, we'll remember that FlashComm server helped make that vision real.


But coupled with Flash MX, this product adds up to much more than an AV toolkit. FlashComm's RTMP (Real-Time Messaging Protocol) isn't just for streaming media. It supports pub/sub event distribution networks that can be wired up one to one or one to many. These events can be produced by AV streams, but also by any of the GUI widgets in Flash's arsenal. What you build with FlashComm are applications whose interfaces are shared in real-time--or, thanks to built-in persistence, asynchronously--across networked PCs among groups of people. Presence, the killer feature of IM, is woven into the fabric. Client-side and server-side code share common APIs and, crucially, both use ECMAScript (more popularly, JavaScript) to achieve a level of rapid-development productivity that Jabber (for example) lacks.

Unlike Jabber, the FlashComm experience doesn't come free. The server, which runs on Windows (soon Linux and Solaris as well), is $500 for the 10-users personal edition, and $4,500 for the 500-users professional edition. Add $500 for the Flash MX development kit, and that's $1,000 to get your feet wet, $5,000 for anything serious. You can try both for 30 days, but the ante's a bit steep for longer term experimentation. For certain corporate and educational customers that won't be a problem. And for users of FlashComm applications, the Flash 6 player is free and on a fast track to ubiquity. There are also more affordable hosting options offered by, for example, mediatemple.net. But in general, FlashComm's price tag will limit the number of developers who explore its distributed-event style of Internet programming, as will the so-far-proprietary nature of RTMP.

Other commercial and proprietary ventures are headed down similar paths. Groove's shared spaces, KnowNow's event-routing technology, and Kenamea's application network are notable examples. I regard these, and now FlashComm too, as infrastructure that complements the Web services movement. So far, the Web services plumbing is mainly about connecting services to services, machines to machines. Evolving in parallel are new ways to connect services to people, and people to one another. Plenty of this is also happening at the grassroots level, as for example Weblog developers push the envelope with innovative hacks like TrackBack and MT-RefSearch. I can't say whether and how FlashComm (or the technology inspired by it) will intersect with the grassroots Internet. I am certain, though, that the ideas it embodies will change how we think about, and create, collaborative software. So, let's explore how it works.

FlashComm 101

The FlashComm server, available for Windows (and soon, Linux and Solaris) is a compact, easy-to-install engine with a Web-based administrative interface that (of course) uses Flash. To jump-start things, you'll want to install the FlashComm components as well. These are paired client-side and server-side objects. The client parts are movie clips sourced by Flash MX from a local components.fla file into an application's .fla file, and thence into the published .swf application. The server parts, which are just ECMAscript files, live on the server under /flashcom/scriptlib/.

An application's .html and .swf files are published to a Web-visible directory under, for example, /wwwroot/flashcom/applications. Each application also has a parallel and non-Web-visible directory under /flashcom/applications/, where persistent objects (if the application creates them) are stored.

In addition to the components, you'll want to download and install the Flash remoting components if you don't already have them. These are mainly used with ColdFusion MX and not required for FlashComm to work, but the included NetConnection debugger is a handy tool to have. Without this kit, you'll get errors when you try to #include "NetDebug.as" as the documentation suggests. As Mike Chambers, Macromedia's Flash community manager, pointed out to me, the server can, in any case, access remote Web services using the same NetServices APIs built into ColdFusion MX's Flash remoting gateway.

Here's how easy things can be using the FlashComm components. I began by dragging a SimpleConnect component onto the Flash MX stage. SimpleConnect combines a login widget with a wrapper that binds the user identity it creates to any of the other widgets. Then I dragged more components onto the stage: PeopleList, Chat, UserColor, and AVPresence. I assigned instance names to each of these, and in SimpleConnect's properties pane, I made two entries:

Application Directory      rtmp://myserver/mychat
Communication Components   [people_mc,chat_mc,colors_mc,av_mc]

Then I loaded up http://myserver/flashcom/applications/mychat/mychat.html from three different computers. In each instance, I logged in as a different person, selected a color for each identity, and typed a chat message. It was a fully functional chat, with presence shown as a changing list of names in the PeopleList widget, and a persistent transcript. When I activated the AV stream on my Webcam-equipped PC, it appeared on all three stations. This is stunning leverage, on the order of what Hypercard and then Visual Basic 1.0 achieved.

What's equally impressive is the transparency of the whole system. Hypercard XFCNs and Visual Basic VBXs, the component technologies of that era, were opaque to the scripter. With FlashComm, both client-side and server-side components are themselves made of script, and thus fully extensible. To find out how, I decided to add a few features. First, I added a button to the application, which enables the user to clear the chat transcript. This is a feature implemented in the server part of the chat component. A few lines of ECMAScript empty the persistence-backed shared object that remembers the transcript on the server, then broadcasts a message to all clients telling them to empty their transient local transcripts.

Extending a Communication Component

On the first try I dragged a pushbutton onto the stage, called it ClearHistory, and wired it to this function. I added to the Actions for Frame 1 of the movie:

function onClearHistory()
    client_nc = new NetConnection();

This worked, but it was the wrong approach for lots of reasons. The function should be part of a modified Chat component, not wired to a stand-alone button. It unnecessarily opened an extra connection to the server, instead of sharing the one that Chat and the other widgets were multiplexing through SimpleConnect. And it needlessly hardcoded the instance name of the Chat component.

Pages: 1, 2

Next Pagearrow