Many of the components in the meeting room are ready to go. However, there will be a little bit of scripting involved to take advantage of Flash's RoomList component. However, there is not a lot of support code for the RoomList because the uses for the component are as varied as the number of Flash developers. In addition, we will use a tiny piece of server-side ActionScript on the Flash Communication Server to make use of the login username.
We have already used the video, chat, bandwidth, and people list components in previous chapters. The only thing that will change in this chapter is how we "hook them up" through the use of ActionScript.
You may be asking, "What about the SimpleConnect component?" As efficient and time-saving as the SimpleConnect component is, we need something a little stronger for the purposes of our meeting room. The reason is that the SimpleConnect component establishes a connection to the Flash Communications Server but has real trouble managing multiple instances of our connections. Our meeting room application relies on multiple connections to access our meeting rooms. Therefore, to achieve our needs, using some ActionScript is not unusual.
Our application will consist of three sections:
The login area
The meeting room
The login area identifies who is invited to the meeting room. The lobby is like the main reception area of a typical office building. It shows that we are in the application, but don't know where to go. The lobby will provide a list of rooms available. Think of the list of rooms as a directory in the lobby. Looking at the list, we can decide where we need to go for our meeting. After we select the room we want to go to, we are then taken to the meeting room area.
On a more technical level, when we log in to the meeting room application, we establish a connection with the Flash Communications Server. The information used in this connection is then saved for later use.
After we log in, we receive a list of the available rooms, using the RoomList component. After we select the room we want to access, our application asks for a new connection using that room as an instance. Why do we need a new connection? Each room will have its own server-side shared object, which is very much like a cookie, except that it is stored on the server, not the user's machine. Each shared object is isolated from the others, which gives the effect of being in different rooms for a chat. In addition, each instance also has its own set of connections. This helps to isolate not only the chat components but also the audio/visual components. From a human perspective, these instances, or rooms, may seem paper-thin. But to the Flash Communications Server , these rooms are lead-lined and soundproofed.
The benefit to the web master, as said before, is that all the power offered in this meeting room application is contained in one application. Any subsequent improvements or changes made to the meeting room application need to be done only once. In addition, the application resides on the server and does not have to be distributed to each member that wants to use the meeting room. Its usage is transparent to the user because it is invoked by HTML. Keeping it server-side means that the user only needs to know how to talk to someone, not how the application works. Most important of all, from the perspective of the participant, it just works.