Thread Rating:
  • 1 Votes - 4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Optional service actions and state variables
31-08-2011, 04:54 PM
Post: #1
Optional service actions and state variables
The UPnP service specifications contain a number of optional actions and state variables. As I understand it, a UPnP AV media server or media renderer provides service description files with a list of the actions and state variables that it supports, and a control point can access these descriptions.

However, I haven't found any code in the ohNet control point stack to parse this service XML and allow a control point implementation to query the availability of actions and state variables. If a control point implementation needs to know this, is it expected to read and parse the service XML itself?
Find all posts by this user
01-09-2011, 03:09 PM
Post: #2
RE: Optional service actions and state variables
At present, a control point would need to parse the service xml to determine which actions are optional. It'd be non-trivial to add ohNet utilities for this; ohNet implements a rudimentary xml parser but many clients will have access to far more powerful xml parsing libraries so are better placed to examine the service xml.

At some point I'll make error codes from actions available through ProxyError. Client code could then check for errors 401/602 to spot which optional actions have been omitted by a given device.

I could also add an option to fetch the service xml if you like.

I wasn't aware that state variables could be optional. Can you point me to the relevant point of the spec please? We'll then need to think about how best to handle this.
Find all posts by this user
02-09-2011, 01:49 PM
Post: #3
RE: Optional service actions and state variables
(01-09-2011 03:09 PM)simonc Wrote:  At present, a control point would need to parse the service xml to determine which actions are optional. It'd be non-trivial to add ohNet utilities for this; ohNet implements a rudimentary xml parser but many clients will have access to far more powerful xml parsing libraries so are better placed to examine the service xml.

At some point I'll make error codes from actions available through ProxyError. Client code could then check for errors 401/602 to spot which optional actions have been omitted by a given device.

I could also add an option to fetch the service xml if you like.

I wasn't aware that state variables could be optional. Can you point me to the relevant point of the spec please? We'll then need to think about how best to handle this.

In ContentDirectory:1, the state variables TransferIds and ContainerUpdateIDs are optional. See Table 7 in section 2.5.1. Asset UPnP's service XML for this service omits the TransferIds state variable.

I agree with your comments about XML parsing. I'm OK with writing code to do this myself. Invoking a service action to see whether it works or fails doesn't seem like right way to discover this. However, it would be good to get a suitable failure indication if an omitted optional service action is invoked.

Would the method to fetch the service XML be added to the CpProxy class? I think it would be useful to have a method there to do this.
Find all posts by this user
02-09-2011, 02:38 PM
Post: #4
RE: Optional service actions and state variables
(02-09-2011 01:49 PM)simoncn Wrote:  
(01-09-2011 03:09 PM)simonc Wrote:  I wasn't aware that state variables could be optional. Can you point me to the relevant point of the spec please? We'll then need to think about how best to handle this.

In ContentDirectory:1, the state variables TransferIds and ContainerUpdateIDs are optional. See Table 7 in section 2.5.1. Asset UPnP's service XML for this service omits the TransferIds state variable.

Thanks. I can see the mentions of "optional" in the xml for ContentDirectory. I'm still struggling to find the relevant part of the spec though. Which doc will I find Table 7 in section 2.5.1 in? I've looked again in the UPnP architecture v1.0 and 1.1 docs and still can't spot it.

(02-09-2011 01:49 PM)simoncn Wrote:  I agree with your comments about XML parsing. I'm OK with writing code to do this myself. Invoking a service action to see whether it works or fails doesn't seem like right way to discover this. However, it would be good to get a suitable failure indication if an omitted optional service action is invoked.

Unfortunately, invoking an action then waiting to see if it fails is the most robust solution (as it copes with buggy devices that serve up hard-coded xml which doesn't show which actions/state variables are not implemented). I recognise there are still reasons for providing access to the service xml however.

(02-09-2011 01:49 PM)simoncn Wrote:  Would the method to fetch the service XML be added to the CpProxy class? I think it would be useful to have a method there to do this.

We could add a method to either CpDeviceUpnp or CpProxy. I have a slight preference for CpDeviceUpnp as users of this can reasonably be expected to understand UPnP service xml, while users of a protocol-independent CpProxy needn't be capable of parsing a protocol-specific service description.

I could probably be persuaded otherwise if you, or anyone else, feels strongly about this.
Find all posts by this user
05-09-2011, 07:07 PM
Post: #5
RE: Optional service actions and state variables
(02-09-2011 02:38 PM)simonc Wrote:  Thanks. I can see the mentions of "optional" in the xml for ContentDirectory. I'm still struggling to find the relevant part of the spec though. Which doc will I find Table 7 in section 2.5.1 in? I've looked again in the UPnP architecture v1.0 and 1.1 docs and still can't spot it.

It's in this document.

(02-09-2011 02:38 PM)simonc Wrote:  Unfortunately, invoking an action then waiting to see if it fails is the most robust solution (as it copes with buggy devices that serve up hard-coded xml which doesn't show which actions/state variables are not implemented). I recognise there are still reasons for providing access to the service xml however.

Waiting for how long? This seems very unsatisfactory, as then my control point is at the mercy of an unresponsive network. For this reason it would be useful to know if the device explicitly states that the action or state variable isn't implemented.

(02-09-2011 01:49 PM)simoncn Wrote:  We could add a method to either CpDeviceUpnp or CpProxy. I have a slight preference for CpDeviceUpnp as users of this can reasonably be expected to understand UPnP service xml, while users of a protocol-independent CpProxy needn't be capable of parsing a protocol-specific service description.

I could probably be persuaded otherwise if you, or anyone else, feels strongly about this.

I don't see a CpDeviceUpnp class in the Java bindings. How would a Java programmer access this?
Find all posts by this user
06-09-2011, 08:20 AM
Post: #6
RE: Optional service actions and state variables
(05-09-2011 07:07 PM)simoncn Wrote:  
(02-09-2011 02:38 PM)simonc Wrote:  Thanks. I can see the mentions of "optional" in the xml for ContentDirectory. I'm still struggling to find the relevant part of the spec though. Which doc will I find Table 7 in section 2.5.1 in? I've looked again in the UPnP architecture v1.0 and 1.1 docs and still can't spot it.

It's in this document.

Thanks

(05-09-2011 07:07 PM)simoncn Wrote:  
(02-09-2011 02:38 PM)simonc Wrote:  Unfortunately, invoking an action then waiting to see if it fails is the most robust solution (as it copes with buggy devices that serve up hard-coded xml which doesn't show which actions/state variables are not implemented). I recognise there are still reasons for providing access to the service xml however.

Waiting for how long? This seems very unsatisfactory, as then my control point is at the mercy of an unresponsive network. For this reason it would be useful to know if the device explicitly states that the action or state variable isn't implemented.

Waiting for less time than it takes for the average action to complete. I'd expect the media server to fail the action immediately (it certainly will for devices published using ohNet).

If you find any poorly written devices which don't respond to invocations on unimplemented actions then you'd need to fall back to parsing service xml. Until then, I'd recommend invoking an action then seeing if/how it fails.

We'll still make a method available to read the service xml so you can go straight to parsing the service xml if you want.


(05-09-2011 07:07 PM)simoncn Wrote:  
(02-09-2011 02:38 PM)simonc Wrote:  We could add a method to either CpDeviceUpnp or CpProxy. I have a slight preference for CpDeviceUpnp as users of this can reasonably be expected to understand UPnP service xml, while users of a protocol-independent CpProxy needn't be capable of parsing a protocol-specific service description.

I could probably be persuaded otherwise if you, or anyone else, feels strongly about this.

I don't see a CpDeviceUpnp class in the Java bindings. How would a Java programmer access this?

Sorry CpDeviceUpnp isn't really visible externally in most language bindings. We haven't implemented it yet but you'll later be able to use CpDevice.GetAttribute("Upnp.ServiceXml.[service name]") to access the service xml.
Find all posts by this user
07-09-2011, 01:37 PM
Post: #7
RE: Optional service actions and state variables
(06-09-2011 08:20 AM)simonc Wrote:  Waiting for less time than it takes for the average action to complete. I'd expect the media server to fail the action immediately (it certainly will for devices published using ohNet).

Does this mean that I need to measure the average time from previous responses, do an async invocation of the optional action, and trigger a timeout if the response hasn't arrived in time? Or can I do a sync invocation and assume that ohNet will do the above processing? Smile

(06-09-2011 08:20 AM)simonc Wrote:  If you find any poorly written devices which don't respond to invocations on unimplemented actions then you'd need to fall back to parsing service xml. Until then, I'd recommend invoking an action then seeing if/how it fails.

We'll still make a method available to read the service xml so you can go straight to parsing the service xml if you want.

I probably would do the latter, which allows me to avoid the test invocation if the service xml doesn't list the optional action. If the optional action is listed, then I would need to go down the more complex path of trying the invocation to see what happens.

(06-09-2011 08:20 AM)simonc Wrote:  Sorry CpDeviceUpnp isn't really visible externally in most language bindings. We haven't implemented it yet but you'll later be able to use CpDevice.GetAttribute("Upnp.ServiceXml.[service name]") to access the service xml.

That works for me.
Find all posts by this user
07-09-2011, 01:42 PM
Post: #8
RE: Optional service actions and state variables
(07-09-2011 01:37 PM)simoncn Wrote:  
(06-09-2011 08:20 AM)simonc Wrote:  Waiting for less time than it takes for the average action to complete. I'd expect the media server to fail the action immediately (it certainly will for devices published using ohNet).

Does this mean that I need to measure the average time from previous responses, do an async invocation of the optional action, and trigger a timeout if the response hasn't arrived in time? Or can I do a sync invocation and assume that ohNet will do the above processing? Smile

Definitely the latter! You can invoke an action using the sync or async APIs and rely on ohNet always completing it. If the action isn't implemented on the target device, the Sync or End function will throw ProxyError. We have yet to add means to determine the reason for such an error. This'll hopefully be added soon.
Find all posts by this user
27-06-2017, 07:59 PM
Post: #9
RE: Optional service actions and state variables
Did the serviceXML code get added (I can't see it in the source).
Find all posts by this user
28-06-2017, 11:01 AM
Post: #10
RE: Optional service actions and state variables
Apologies - I forgot all about this. To reduce the chances of this being missed again I've raised it internally as a bug (#5409).
Find all posts by this user


Forum Jump: