Implements the MTP framework parser/router singleton.

The MTP framework parser/router singleton is responsible for directing received MTP operation request (and event) datasets to the appropriate data provider(s) for processing, and performs the following major functions:

1. Parses received operation request and event datasets to extract and coarse grain validate routing data (ParseOperationRequestL). 2. Executes one or more routing algorithms to select the set of data provider targets able to service the operation or event (RouteOperationRequestL). 3. (Optionally) dispatches the request or event (ProcessRequestL).There are two basic scenarios which the parser/router must handle, and a different set of APIs is provided for each. These scenarios are:

1. The initial routing of operations as they are first received. This routing is initiated by the MTP framework using the ProcessRequestL API. This API executes all three of the functions identified above. 2. The secondary routing of those operations which cannot be dispatched directly. Either because they require the combined processing capabilities of multiple data providers to produce an aggregated response, or; because they cannot be routed using data available during the operation request phase and can only be routed to their final target using data available during the operation data phase. This secondary routing is performed by the MTP framework's proxy data provider using the ParseOperationRequestL and RouteOperationRequestL APIs. These APIs respectively execute the first two functions identified above, which are separated in order to allow additional information to be added to the routing data by the proxy data provider. The third function identified above is not executed in this scenario, since a very different dispatching mechanism must be used by the proxy data provider.The parser/router implements a number of different routing algorithm types, some of which are further decomposed into sub-types to achieve a finer level of routing granularity and control. In combination these algorithms support the following general routing mechanisms:

1. Device - A subset of device oriented MTP operations are always dispatched to the device data provider. 2. Proxy - A subset of MTP operations cannot be dispatched directly. Either they require the combined processing capabilities of multiple data providers to produce an aggregated response, or cannot be routed using data available from the operation dataset alone. These operations are dispatched to the proxy data provider for additional processing. 3. Object Handle - MTP object handles generated by the MTP framework are encoded with a data provider identifier to efficiently route those MTP operations which supply an object handle as a parameter. 4. StorageID - MTP storage identifiers generated by the MTP framework are encoded with a data provider identifier to efficiently route those MTP operations which supply a storage identifier as a parameter. 5. Operation Parameter - On being loaded each data provider supplies a set of configuration data (MTP operation codes, event codes, object property codes, device property codes, and storage system types) which collectively define the set of MTP operation requests that it wishes to receive. 6. Request Registration - Data providers may optionally register MTP operation request datasets with the framework which, when subsequently matched, will be routed to them. This mechanism is used to route those MTP operation types which are paired to complete over two transaction cycles (e.g. SendObjectInfo/SendObject). It may also be used to route vendor extension operation requests.

The following routing algorithm types are implemeted:

1. Operation Parameter Routing

Operation parameter routing is the primary routing mechanism and by default is enabled for both initial and secondary proxy routing scenarios. Operation parameter routing involves selecting one or more data provider targets using routing data obtained from or related to the supplied operation dataset parameters using one of the following sub-types:

o Parameter lookup routing sub-types, which match operation dataset parameter data with the set of supported capabilities registered by each data provider on being loaded, or; o Parameter decode routing sub-types, which extract data provider target identifiers encoded into the parameter data itself.

The parameter lookup routing sub-types are table driven and utilise binary search techniques to minimise processing overhead. The following parameter lookup routing sub-types (tables) are implemented, each characterised by the combination of parameters they require to map to a routing target:

o DevicePropCode o ObjectPropCode o OperationCode o StorageType o FormatCode + FormatSubcode o FormatCode + OperationCode o StorageType + OperationCode o FormatCode + FormatSubcode + StorageType

These routing tables may be further characterised by modifier flags which e.g. allow or disallow duplicate entries, or specify ascending or descending sort orders which in turn can manipulate the order in which proxy targets are processed.

The parameter decode routing sub-types extract routing target identifiers directly from the operation dataset parameter data itself. The following parameter decode routing sub-types are implemented:

o Object Handle o StorageID

2. Framework Routing

By default, framework routing is enabled during initial operation routing only and not during secondary proxy routing. Framework routing directs a sub-set of MTP operations to one or other of the framework data providers. Using one of the following routing sub-types:

o Device DP. A fixed sub-set of MTP operations are always dispatched to the device data provider. o Proxy DP. A fixed sub-set of MTP operations are always dispatched to the proxy data provider. In addition, any operations which yield multiple routing targets will also be routed to the proxy data provider.

3. Request Registration Routing

By default, request registration routing is enabled during initial operation routing only and not during secondary proxy routing. Data providers may optionally register MTP operation request datasets with the framework which, when subsequently matched, will be routed to them. This mechanism is used to process those MTP operation types which are paired to complete over two transaction cycles (e.g. SendObjectInfo/SendObject). It may also be used to route vendor extension operation requests.

Request registration routing does not implement any routing sub-types.