Date: Fri, 29 Mar 2024 04:35:48 -0600 (MDT) Message-ID: <47220881.4824.1711708548512@lv-confludc01.cablelabs.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_4823_68348622.1711708548511" ------=_Part_4823_68348622.1711708548511 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
The purpose of the document is to explore the tasks required, an= d issues involved in incorporating 3rd party UPnP implementations. On= e of the first questions to ask is what parts of the implementation are goi= ng 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 implemen= ts the HN-EXT API in terms of this underlying implementation. Here is= an enumeration of several of the functional areas implemented, please refe= r to the HNP specification for details.
The 3rd party implementation may account for some or all of the above ar= eas of functionality.
The RI implements most UPnP related activities in the OCAP Java stack. &= nbsp;The exception to this is servicing HTTP requests for recorded and live= content. In the case of content delivery the RI listens and takes th= e request in from the Java stack, formulates and sends the HTTP headers, th= en passes the socket through to the MPE porting layer to a native C impleme= ntation that is responsible for sending the content that was requested.
All advertisement and listening to incoming requests is done using an op= en source 3rd party library called Cybergarage. The version of Cyberg= arage we use is 1.6, but it has been heavily modified in order to satisfy r= equirements unique to OCAP as well as to be compliant and pass UPnP & D= LNA certification tests. In OCAP 1.2, the UPnP Diagnostics API = was introduced and includes unique requirements that call for the ability t= o view and modify all incoming and outgoing message traffic, including SSDP= and SOAP requests and responses. This low level API is not tradition= ally found in 3rd party libraries and can represent a substantial amount of= work by integrators in order to satisfy the specification.
There are several approaches that can be taken. Each has a differe= nt level of involvement and risk.
This is the class that initializes the UPnP device and services provided= by the RI. This could be left alone if using the UPnP Diagnostics AP= I to initialize the device and services.
The implementation here utilized the Cybergarage Device class. Thi= s could be replaced with JNI calls or use of another Java API that provides= similar semantics.
This class holds an in memory object graph of sub-devices, services, ico= ns and state variables as constructed using the UPnP Diagnostics API.  = ;Since Cybergarage like many 3rd party APIs does not allow for online manip= ulation of it's data structures, this class will remove and reload the Cybe= rgarage Device class every time there is a change to the object graph repre= senting this device and it's components. After reloading this class w= alks the re-created Device in Cybergarage and reassociates the Cybergarage = constructs with the UPnP Diagnostics equivelents, Cybergarage Service to UP= nPManagedService and so on.
These interfaces are perhaps the most difficult to implement with a 3rd = party library. We had to heavily modify the cybergarage code in order= to implement the APIs that allow this feature.
Data structure that contains all of the properties for a container or it= em. In the RI implementation this class is used in both client and se= rver functionality. In order to facilitate both functions, MetadataNo= deImpl can be constructed from and can produce an XML DIDL-Lite fragment. &= nbsp;If a reimplementation includes CDS functionality, there needs to be a = mapping created for MetadataNode. There are three main areas of diffi= culty to be aware of.