This chapter is from the book
This chapter is from the book
This chapter is from the book
Extending the Possibilities
You can continue to add functionality to the conference clients and application, or change the application's capabilities to work with other applications you have created. In this final section of the chapter, you can review some ideas to expand the potential of the conference application.
Authenticated Access
In the real world, you wouldn't likely want to leave bandwidth- and server-intensive applications available to anonymous visitors of your Web sites or Web-enabled interfaces. Using Flash Remoting routines, LoadVars, or other data-enabled ActionScript objects and methods, a Flash client can send user name and password information to an application server for login verification. Once the user is authenticated, the Flash client can access the URL of a FlashCom-enabled client.
Xref
Constructing authenticated user access is explored in more detail in Chapter 14.
Synchronization and Latency Problems
If you conduct several conference recording sessions and view the sessions with the retrieval client, you will likely witness streams that drift out of sync over time. The reason for this problem is latency. If either user's connection to the server is not fast enough to support the real-time transmission of audio and video data, or if the server's bandwidth is severely taxed, the accuracy of the recorded streams will suffer. Latency can also affect playback of recorded streams; if the viewer's connection speed is not fast enough, the data rate for each stream can become uneven, allowing one stream to receive more data than the other.
You can limit the severity of these problems in a few ways:
Instruct participants to use the least-bandwidth-intensive setting in the SetBandwidth component instance. Unless you have modified the presets, the Modem setting uses the least amount of bandwidth.
Use the conference application specifically for LAN-based environments where network latency becomes less of an issue.
Track and store sync times in each stream as it records during the live conference session. During playback, compare the sync times across the streams. If one stream gets ahead of another, pause the faster stream until the other stream catches up. To store times in the recorded stream (that is, the FLV file), use the Stream.send() or NetStream.send() method to broadcast the sync times. Data sent over a live stream via the send() method is synchronously saved with the audio and video data of the recorded stream.
Tip
Look for updates and new versions of the conference application on the book's Web site at http://www.mxbook.com.
Session Data Storage
While recorded streams must be directly saved and accessed by client-side or server-side ActionScript within the FlashCom application, the data stored with the persistent remote SharedObjects for the conference application can be handled with Flash Remoting, an application server, and a data source. If you want to manage thousands of recorded sessions and users, you can store user information and the recording times data in a relational database. In this way, you can access this data with other non-Flash interfaces created in HTML with Macromedia Dreamweaver MX.
Removal of Stored Data
If you do not implement a separate data source for the session data of each recording session, you may want to create another Flash client movie, which allows you to delete streams and remote SharedObjects in the conference application. You can create an interface that allows you to choose a conference title and remove the associated time tracker SharedObjects and properties in the savedCalls SharedObject.