[vtp-dev] Media Defaults

[Trip Gilman <trip@xxxxxxxxxxxxxxx>]

Title: Media Defaults

Hello Everyone,

I have completed adding several new features to the VTP.  I initially set out to add support for workspace and application level default values for the common media settings, such as Barge-In and Interdigit Timeout.  While developing this feature I realized a few existing features would need to be modified and the changes would provide an excellent opportunity to fix some long standing design related defects.

The changes also required some pretty substantial changes to the schema of our application xml documents.  I wanted this update to be transparent for the application developer so I added an update mechanism in the load and store components.  The xml content can now be transformed prior to being loaded to perform migration from version to version or even component to component.  This will also be very valuable moving forward as it provides the capability for us to make additional changes to the schema as we release new versions of the tooling without the constant worry of backwards compatibility we have now.

I have been developing these features in the media-defaults branch of the desktop plugins.  I will be merging these additions into the trunk today.  Below is a more detailed list of the changes made and their effects:

• [Design Enhancement]  Significant changes to the xml contained in the model areas of the CallDesign documents.  Components are no longer in control of their containing xml elements.  Our current model has been to allow the component to write it xml element and children completely.  The container xml element has been moved up into the corresponding model base class.  Below is an example of the change when applied to a primitive element:
  

> <primitive-element type=”endblock”>
> > ...
> </primitive-element>
>
> is now

> <element type=”primitive”>
> > <properties>
> > > <property name=”type” value=”endblock”/>
> > </properties>
> > ...
> </element>

> The xml for Elements and Configuration Managers have both been updated in this way.  This allows a more robust parsing and processing of these documents.  The model can now detect missing components more easily and provide more relevant information to the user when problems occur, instead of an xml tag name and namespace.

• [Design Enhancement]  The xml elements corresponding to a model element’s configuration managers have been moved from being directly contained by the model element’s xml element to being contained by a new xml element.  The new xml element is <configuration>.  This change was made with the introduction of the <properties> structure in the model element xml (illustrated above).
  

• [New Feature]  To facilitate the migration from the old model xml format to the new format, a legacy conversion system has been added that allows people to provide converters for their custom element types to the new format.  Converters for the standard four VTP element types Primitive, Custom Integration, Dialog, and Fragment have been provided.  The standard editors only support these four types so unless someone has created a custom editor there should not be any additional element types to convert.
  

• [New Feature]  The Brand object now contains an id field that uniquely identifies it.  This allows components that store references to brands to be more robust and also opens the possibility of brand renaming later.
  

• [Design Enhancement / New Feature]  The MediaBindingManager configuration manager has been replaced with a new configuration manager implementation, GenericBindingManager.  The new API provides the same general capabilities of the old but is much more robust and will allow extension moving forward.  The old system had a flaw in the way it stored the brand binding information.  Brands were stored by name without any path information which caused the all brands to require a unique name.  This limitation has been lifted, and brands now only require a unique name within the same parent brand.  Another enhancement offered by the new API is that the binding information can now be queried.  The previous system stored the language/brand/interaction type information as a single string without delimiters.  This only allowed requests for bindings using all three elements.  The new API stores the information in a tree format so all levels of binding are searchable.
  

• [New Feature]  Because the manager id and xml structure changed with the manager API, a new configuration manager upgrade system was created.  Developers can now register converters to support migrating the xml from one version to another or even from one manager type to another.  Converters will automatically be chained together to reach the highest version of a manager possible.  The conversion process takes precedent over the available managers.  For example if there is a manager for com.company.config version 1.0.0 and a converter that migrates com.company.config version 1.0.0 to com.company.config-new version 1.0.0, the converter is run and the manager for com.company.config-new is used for the application.
  

• [New Feature]  The model loading component keeps track of any legacy or version/type conversions that are performed while loading a document.  If conversions were needed, an confirmation dialog is displayed to the application developer.  The dialog notifies the developer that the document required conversion and that it will be permanently changed the next time the document is saved.  The application developer can choose to continue to open the document (it will be upgraded permanently upon the first save) or cancel the operation.
  

• [New Feature]  All primitive elements and their UI components that were using the old media API have been converted over to the new generic manager.  The interface presented to the application developer remains unchanged.
  

• [New Feature]  A new API has been added to support default values for common media settings.  There are currently two implementations provided.  The first is a workspace level system that stores its data in the desktop.core plugin’s preference store.  The second allows application level settings and is managed by the voice tools design project implementations for application and fragment projects.
  

• [New Feature]  Developers can register their own UI panels that provide an interface to manage the default settings for a particular element type.  UI Panels are provided for Play Prompt, Question, Option Set, and Record.
  

• [New Feature]  A preference page has been added to provide an interface for the workspace level default values .
  

• [New Feature]  A new properties page has been added to both application and fragment projects that provides an interface for application level definition of default values for common media settings.  All application level settings initially inherit their values from the workspace.  The application developer can pick and choose which settings to override.
  

• [New Feature]  All media settings properties panels for the interactive primitive elements (play prompt, question, option set, record) have been updated to support the new application and workspace level default settings.
  

• [New Feature]  All media settings properties panels have been enhanced to explicitly show which settings are being inherited from parent brands or application/workspace level defaults.  The application developer now explicitly marks a setting as overridden.
  

• [New Feature]  The exporter has been updated to support the generic bindings API.
  

• [New Feature]  The exporter now uses the application/workspace level default settings if no explicitly settings were made by the application developer.
  

The upgrade mechanisms should provide support for nearly all applications generated with the 3.x stream of the VTP.  I do expect there may be some issues with some of the older applications so please feel free to drop a note in newsgroup or here if you find something that doesn’t upgrade correctly.  For most users this update should not have any deleterious effects.

Trip Gilman