Upcoming Changes 2
We’re considering a couple of upcoming changes. These things are a ways out, but I figure the time to bring them up is now. The first one was just posted, the second is posted below.
The hardware that is supported by the SDK is going to continue expanding. As this continues to happen, assumptions have to change. This is essentially, Joel's Law of Leaky Abstractions. In some cases, this is a fairly simple matter. For example, the Voyager 510 system doesn't have a smart button like the CS50/60-USB. It means you'll never get a smart-button-pressed event while a Voyager is connected, but that's easy to deal with. The hardware we're looking to expand to is a little harder to deal with. Specifically, we’re going to start adding support for wired headsets. That leaves us with a problem of what to do with the AudioEnabled property.
Our plan in these cases is to treat AudioEnabled as a read-only property. It won't always be set to true. In some cases it may be possible for the USB end to be connected to the PC (and thus the SDK is attached to the device), but the headset end to be disconnected. This is analogous to the radio link being down on a wireless headset so AudioEnabled will read as false. When the user connects the headset it will become true and an AudioEnabledChanged event will be issued. The reverse obviously won't work. Writing true to the AudioEnabled property won't cause the headset connector to leap into the socket.
This leaves us with the question of what do with requests to change the AudioEnabled property. The current plan is to silently do nothing, so as to maximize compatibility. The alternative would be to return E_FAIL or E_NOTIMPL, which might crash the SDK user's application. The down side of silently doing nothing is that it might leave SDK integrators needing to check AudioEnabled after they changed it; an awkward construction at best.
Another implication of this is that events may arrive in an unexpected order. Currently you aren't likely to receive talk-pressed events when you think AudioEnabled is false. With a wired setup this is much more likely.
Finally, we're thinking that some sort of interface to determine device capabilities may have some value. It would allow SDK integrators an easy way to programmatically determine whether AudioEnabled could be set or not.
None of this is set in stone yet, so if you have any opinions on how this sort of things should be done, now's the time to say something.
The hardware that is supported by the SDK is going to continue expanding. As this continues to happen, assumptions have to change. This is essentially, Joel's Law of Leaky Abstractions. In some cases, this is a fairly simple matter. For example, the Voyager 510 system doesn't have a smart button like the CS50/60-USB. It means you'll never get a smart-button-pressed event while a Voyager is connected, but that's easy to deal with. The hardware we're looking to expand to is a little harder to deal with. Specifically, we’re going to start adding support for wired headsets. That leaves us with a problem of what to do with the AudioEnabled property.
Our plan in these cases is to treat AudioEnabled as a read-only property. It won't always be set to true. In some cases it may be possible for the USB end to be connected to the PC (and thus the SDK is attached to the device), but the headset end to be disconnected. This is analogous to the radio link being down on a wireless headset so AudioEnabled will read as false. When the user connects the headset it will become true and an AudioEnabledChanged event will be issued. The reverse obviously won't work. Writing true to the AudioEnabled property won't cause the headset connector to leap into the socket.
This leaves us with the question of what do with requests to change the AudioEnabled property. The current plan is to silently do nothing, so as to maximize compatibility. The alternative would be to return E_FAIL or E_NOTIMPL, which might crash the SDK user's application. The down side of silently doing nothing is that it might leave SDK integrators needing to check AudioEnabled after they changed it; an awkward construction at best.
Another implication of this is that events may arrive in an unexpected order. Currently you aren't likely to receive talk-pressed events when you think AudioEnabled is false. With a wired setup this is much more likely.
Finally, we're thinking that some sort of interface to determine device capabilities may have some value. It would allow SDK integrators an easy way to programmatically determine whether AudioEnabled could be set or not.
None of this is set in stone yet, so if you have any opinions on how this sort of things should be done, now's the time to say something.
posted by aunomvo at 2:50 PM
0 Comments:
Post a Comment
<< Home