The purpose of the document is to outline the tasks required, and issues involved in incorporating third-party UPnP implementations. One of the first questions to ask is what parts of the implementation are going to be replaced. The OCAP RI implements several aspects of UPnP in order to be a DLNA compliant DMS and DMP. On top of that, it implements the HN-EXT API in terms of this underlying implementation. Here is an enumeration of several of the functional areas implemented, please refer to the HNP specification for details.
- UPnP Control Point discovery, action invocation, subscription requests and notifications
- UPnP Device advertisement as well as handling of action, state variable and subscription requests
- UPnP Connection Management Service
- UPnP Content Directory Service
- UPnP Scheduled Recording Service
- HTTP requests for icons
- HTTP requests for recorded content
- HTTP requests for live content
The 3rd party implementation may account for some or all of the above areas of functionality.
Approaches
There are several approaches that can be taken. Each has a different level of involvement and risk.
- Implement that UPnP Diagnostics API from scratch, native in Java. The approach is rather involved, but will allow for a complete and proper implementation.
- Replace the cybergarage stack with another Java API.