Configuration data encompasses runtime preferences, font definitions, layout options, module setup, media metadata
and edit decision lists (mashes). All of this data is passed to the applet
in XML format, either from static text files or dynamic CGI responses.
When the applet first loads, a single request is made to the server for the initial configuration, based on the
config variable supplied
as part of the HTML that loads the applet.
Learn more in Applet Embedding.
After the XML in this first configuration request is loaded, the applet can be made
to request additional configuration by specifying a URL for the
config attribute of any tag. Once loaded, the XML in these
secondary files is parsed as if it were part of the initial configuration, potentially loading
even more configuration if it's specified.
This open-ended approach to configuration loading allows data to be arbitrarily organized
under different URLs, with some pointing to static files and others to CGI scripts.
Typically this functionality is used to separate different types of
configuration, with user specific data provided dynamically through authenticated CGIs.
For instance, a particular
URL might return the
tags for the assets the user has previously uploaded
while a static file might contain the
tag that's used to describe the
interface layout. Or these tags could be dynamic as well, to provide different editing
interfaces for different users.