Skip to main content

Mpeos POD Feature List API

6 replies [Last post]
amirn
Offline
Joined: 2009-05-06

The API description for retrieving the Feature List is not clear.

After looking at the mpeos generic feature control APIs and matching them to the OCAP spec objects, It appears as if the mpeos APIs incorrectly reference the POD/CableCard as the source for the feature list. I believe that the mpeos APIs should be referring to the Host features.

Could you please clarify whether these APIs are meant for retrieving the Feature List from the Host or from the CableCard?

Thanks.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
greg80303
Offline
Joined: 2008-07-03

Which APIs are you referring to? If you are referring to these:

mpeos_podGetFeatures
mpeos_podGetFeatureParam
mpeos_posSetFeatureParam

then, I believe they are correctly associated with the POD for retrieving/setting Host Generic Features as described in CCIF2.0-I18 Section 9.15. Otherwise, we need more information as to which APIs are confusing you.

G

amirn
Offline
Joined: 2009-05-06

Yes. These are the APIs I was referring to. Thanks

kenrowland
Offline
Joined: 2010-02-19

I would like further clarification on the features referred to by mpeos_podGetFeatures, mpeos_podGetFeatureParam, and mpeos_podSetFeatureParam. The CCIF spec clearly states that there are host features and card features and the two are independent. There can be an intersection, but it is not required. During card bring up, the host and the card exchange their feature lists as well as the settings for each.

There are specific sequences required to change features that may be present in both.

The pod api is not clear as to which set of features it refers. Does it refer to the host maintained set of features or the card set of features.

Thanks.

greg80303
Offline
Joined: 2008-07-03

The POD APIs are meant to enumerate, set, and retrieve the Host features. These are mostly to facilitate the implementation of the org.ocap.hardware.pod.POD APIs. The POD APIs makes it clear that these features are "host" features. The native CableCARD stack is expected to handle update of card features (if supported) based on updates to the associated host feature.

Please let me know if this is not enough information to answer your question.

G

kenrowland
Offline
Joined: 2010-02-19

Is there a minimal list that is required? When I don't return a list the stack will throw an array out of bounds exception. I looked at the java code that is processing the features and it is looking for the time zone feature, which was not returned.

greg80303
Offline
Joined: 2008-07-03

From reading the spec, I don't think that any features are required. If what you say is true (stack throws exception if timezone feature is not available), could you please create an IssueTracker bug for this?

G