In previous chapters we experimented with a quiz game. Its database is expressed in XML, and we have learned a variety of ways to dissect the data and display it to the user . The actual data is stored on the server as a simple XML file, which is accessed as a whole and selected from by the Flash application.
Data storage in XML files is far more sophisticated and robust than storage in simple text files. It is even, in some real senses, an improvement over sophisticated solutions like Generator and Cold Fusion. Unlike those proprietary, closed technologies, an XML service is simple, public, and open . A wide variety of tools can operate on the data from many different perspectives.
However, a file is just a file. Unless the file is actively altered , the data does not change. So it has the problem of being static.
Additionally, the file must be loaded in its entirety. Any process of selection must be done on the client side (in the Flash program) after the entire file is downloaded. This would be a grave inefficiency if, for example, we have software that presents a random "tip of the day" from a heap of 300 tips. It would be necessary to tax the server, the client, and the user's patience by downloading all 300 messages so that a single one could be displayed.
A third problem is security. The user might be permitted to see just a part of a database for commercial or strategic reasons. It is a compromise of security to send all the data to the user, even if it is supposed to go to a client that makes only certain portions visible. If the file is sent, there are many ways to capture all the data, from simply accessing the XML file directly with a modern browser to monitoring the IP packet traffic.