Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Incompatible change in device stack
04-10-2011, 02:40 PM
Post: #1
Incompatible change in device stack
The next release of ohNet will be binary incompatible for users of the Device stack, requiring updates to all providers. (Users of the Control Point stack are unaffected so can safely stop reading now.)

As the first step towards supporting optional state variables, providers now have to enable the state variables they support. This requires a little more code in each provider but is consistent with what is already done for actions so shouldn’t be too troublesome. Simply add code of the form

EnableProperty[name]();

(one call per state variable) at the start of your provider’s constructor.
Its important that this is called before any call to SetProperty[name](). It is sometimes necessary to enable a property before certain actions so its best practice to always enable all properties before any actions.

Several further commits will be required to fully support optional state variables. These later changes will all be binary compatible so won’t require any updates from you.
Find all posts by this user
17-04-2012, 10:44 PM
Post: #2
RE: Incompatible change in device stack
Are optional properties supported yet? I've been trying to make them work by adding <Optional/> in my <scpd> definition (copying the example in ContentDirectory1.xml), but this doesn't seem to make any difference. I'm trying to do this with my own service definition, in an attempt to allow a newer level of the control point to interoperate with an older level of the service. The newer level has an additional evented property that the older level doesn't have.

I'm getting an assertion error on the control point side when the control point tries to access the optional property value. Is there any ohNet API that the control point can call to discover whether or not the server supports an optional property?

For now I've abandoned the optional property approach and I'm using other means in the control point to discover the level of the service. It would be much nicer if I could do this with an optional property.
Find all posts by this user
18-04-2012, 04:39 PM
Post: #3
RE: Incompatible change in device stack
I'm afraid I haven't had time for this yet so there's still no support for optional state variables.

You could probably figure out which properties a server supports by calling GetAttribute("Upnp.DeviceXml") on a CpDevice, parsing the xml returned to determine service xml locations, then fetch the service xml using a HTTP GET, then parse the xml this returns. (I'm not suggesting this as a final solution but its an option if that'd help in the short term.)
Find all posts by this user
20-04-2012, 02:57 PM
Post: #4
RE: Incompatible change in device stack
Thanks for the suggestion. I've decided to carry on with my current workaround, which is a bit easier for me than parsing device XML and service XML.
Find all posts by this user


Forum Jump: