Data Exchange
Exchange Manager
The Exchange Manager is a central broker to manage inter-application/inter-device communication. Requests to the Exchange Manager contain verbs (“get”, “store”, “play”), data (qualified by mime-type) as well as other parameters used to identify the specific item to be affected by the request. Use cases of the Exchange Manager include beaming a contact to another device, taking a picture using the camera from an MMS application, looking up a vCard based on caller ID, viewing an email attachment, etc.
The Exchange Manager is an extensible framework: new handlers can be created for new data types and actions as well as for new transports (e.g. IR, local, Bluetooth, SMS, TCP/IP, etc.)
There is a need for any application to be able to perform different tasks (such as "play", "get", "store", "print"…) on a variety of types of data. This component offers a simple, yet expandable, API that lets any application defer the actual handling of the data to whoever declared he was the handler for this action/type-of-data pair. In addition, the destination of the request (where the action will actually be performed) can be specified as the local device or a remote location. This opens up new universal possibilities such as directly send a vCard to someone through Internet while being on the phone with him.
This component also implements the legacy “Garnet” Exchange Manager functionality (send data to a local or remote application). This simply corresponds to the action 'store'.
The Java VM also implements a similar functionality (JSR211 – CHAPI). It is foreseen that the Java and native components will interoperate. In other words, a Java application will be able to send a vCard to a remote device through IR, as well as receive data from a local native application, for some examples.
Features
The purpose of this component is to enable an application or system component to request the system to perform some action on some data, without knowing who will carry and fulfill the request. In addition, the client can request that the action be performed either on the local device or on some specific other destination (phone or desktop PC…), using any available transport. This opens up new interesting scenarios that were not possible to do before.
An application that implements a service it wants to make available to others registers a handler to tell the system it can perform this specific action on this specific type of data. The handler may also specify that it will accept only Local request, or that it will accept all requests. Each registered handler is valid for only one combination of action/data type. The action/data type is defined by a verb, and a MIME type (e.g. 'store' - 'text/vCard').
Transport modules are responsible to carry the request from the source to the destination device. When the request arrives at the destination (which may be the local machine), the transport will hand it to the exchange manager who will then invoke the corresponding action handler to do the actual work. A result may be sent back to the initiator, which means it is also possible to use this component to retrieve some data (not only send it), or pass some data and get it back modified in some way. An obvious use case would be to use your phone to lookup a contact in your desktop PC address book, or retrieve a contact's photo and name given its phone number.
Handlers can be registered or unregistered at any time. A board game would register the 'moveplayer' action (a handler to receive other players moves) when it is launched, and would send its own moves by requesting this same action from the other user device. The game would unregister the handler when it quits. Note that this example does not mean exchange manager could be used as a network media to handle more than peer to peer exchanges.
An application cannot verify the availability and identity of a handler and this would not make sense in the general usage (it is the goal of the exchange manager to be able to have an unknown handler execute a request). If an application needs to authenticate the handler, then this means it looks for a very precise handler it knows and in this case, it could use, for example, data encryption to ensure only the person with the right key can understand the request.
Transports are independent modules that can also be added or removed at any time. It is unlikely though that many will be added by third parties as we will provide Local, IR, BT, SMS, and TCP. Non-ALP destination systems must run an exchange manager daemon and transports as well. Except for the handler invocation part, this should be the same code for any Linux platform (the sharedlib, daemon and transports only use standard Linux and GTK services). It would be easy, for example, to implement a new encrypted transport, should the need arise. The library provides a standard UI dialog to let the user select a transport and enter the relevant parameters. If the transport information is missing in the request, the Exchange Mgr will itself pop this UI up at the time it needs the information. If the transport determines that the destination address is missing, it will also popup an address selection UI.
Verbs can be accompanied by parameters. Only a few parameters are common to all verbs (e.g. a human readable description of the data that may be used to ask the user if he accepts what he is receiving). Parameters are passed as a tag/value pair (the value being int or string). Some are mandatory but most are optional and depend on the specific handler definition. Using parameters, the result of an action handler can be precisely customized to the client needs.
A non-exhaustive list of actions that will be defined include 'store', 'get', 'print', 'play'.
Parameters can be used by the action handler to find out how exactly it should perform its action, or by the transport module to get the destination address or other transport specific information.
An Exchange Manager daemon is started at boot time (or at any other time). The daemon is used to listen for incoming action request for all transports. When a transport has an incoming request ready, the daemon dispatches it to the right action handler. The action handler then performs its duty, and returns the result back to the transport. The answer is then sent back to the originator.
When the originator is Local, the user is never asked to accept the incoming data. When the originator is remote, it depends on the transport whether a user confirmation is asked or not. For IR, it is assumed that the user implicitly accepts as he directs his device toward the emitter (it is still to be decided if we ignore the possibility that someone would be able to beam something to you without your consent while you have the device turned on). For BT, it depends whether the connection is paired or not. For SMS, the mobile network identifies the originator (in addition, there is no 'connection' with SMS). For TCP, the transport configuration will tell whether the originator IP is authorized, and it will ask if not.
For handlers that are essentially data consumers and don't return anything (like 'store'), it may make sense to let multiple handlers register for the same verb/data. For this reason, it is left to the handler to specify if it must be unique or not at registration time. In case it must be unique and someone tries to register a second handler for the same verb/data, the user would be notified and he would have the responsibility to arbitrate which of the two handlers should be the active one.
To maintain transfer compatibility with phones or old PalmOS devices, the initiator may set a parameter to tell he wants to use Obex as the transport. In this case, the only verb allowed is "store". The transport plug-in will recognize this parameter and send the data using the OpenObex daemon. As well, a transport plug-in can also receive data from the OpenObex daemon. It would treat that like an incoming connectionless 'store' action on the received data.
For all other combination of action/data type, the transport protocol is ours (or third party in case of third party transport). Obex protocol is handled by the OpenObex library. SMS NBS transport is handled in the SMS component. Some specific Bluetooth profiles (e.g. basic imaging profile) could also be handled by the Bluetooth transport in order to maximize compatibility with other kinds of devices.
An AlpExgRequest is the only entity an application works with. It is an opaque structure that contains all the information characterizing a request: the verb, the parameters, the data reference and the destination. There are APIs to set and get all of them. The data itself can be specified in multiple ways: file descriptor (data will be read from this fd by the transport) or URL (URL is sent, and action handler will access data through the URL).
Digital Right Management (DRM)
DRM is an OS component that defines how action rights associated to a file will be granted. For example, you may have a song that your are allowed to play, but not copy or transfer to someone else. DRM will ensure that the user cannot go around the rights he has on this file. We are working on a DRM framework design; current thinking is that there will be a common interface for DRM and the framework will be using ALP’s underlying security services for rights checking.
The Exchange manager is all about calling handlers to perform actions on data, and it seems like it would be one of the primary client for DRM who also has to do with playing or copying music, vidéo or other media. However, if one thinks a little bit further on how it will effectively work, it turns out that the Exchange manager itself may not be implicated at all with DRM (but the request issuer or the handler will obviously be).
It's not clear at the moment which DRM standard we will support. However, this will probably be OMA DRM 2.0(a standard currently being established in the mobile area), and the following assumes that. In this standard, the content data is always transferred in an encrypted form, and a separate "rights" object (encrypted as well) contains the rights. The rights object itself is cryptographically bound to the user device.
It is therefore absolutely possible to transfer the encrypted content data at will (it is even a requirement in OMA DRM 2.0 to be able to do that).
It is thus very likely that the exchange manager itself will never have to deal with the DRM manager.
Back to "About Hiker... "
|
