On optionality

All,

This came up a lot in the recent discussion, but we did not have time to discuss it on the call yesterday.

All optional features are a pain for application developers, but I think we need to distinguish between two types of optionality:
(a) features that are just optional for UAs to implement
(b) features which are not present on all devices

It is in our power to reduce or eliminate features of type (a) from our specification, but the fact that different devices have different capabilities is just a fact of life over which we have limited influence. It would be ridiculous, for example, for us to say that because *some* devices support 3D video, *all* must support it. With respect to such features, there are three possibilities:
(i) don't provide support for any such features in the specification
(ii) require that where device support is absent, the UA must provide fall-back support in software
(iii) the feature is optional in the specification (with some kind of capability discovery, although this could just be the possibility to return NOT SUPPORTED to some operation).

(i) is a rather draconian least-common-denominator approach that would make our gadget lives rather dull (IMO).

(ii) should be preferred wherever possible.

But there remain some cases where (ii) is not possible, and then we have (iii). (ii) is not possible where the feature relies on hardware support (by definition). Whether a sensible software fall-back exists needs to be examined on a case-by-case basis, but sometimes there will be nothing of value that can be done without the hardware capabilities.

The model of optionality we have in our specification now is Algorithms. It's wrong to characterize this as "void *dovoid(void*)". What we have is several instances of "<explicit type> do<explicit operation>( void *, <other explicit parameters> )". Yes, the first argument is completely open (The AlgorithmIdentifier, containing AlgorithmParameters), but what the method does, the return type and the input message data are explicitly defined. And the situation is the same for all our operations. 

This might not be the best model. Indeed we have an ISSUE to be clearer about algorithm parameters vs. operation inputs, which if solved could lock things down ink a cleaner fashion.

For the issue of retrieving pre-existing keys, there is certainly a connection with hardware. And there is diversity in what is supported by devices, just as there is diversity in algorithm support. And there is no imperative to support everything day one (just as with algorithms). So I find it hard to understand why the existing model for optionality shouldn't apply here too.

What I hope we can do is distinguish between arguments about optionality generally - and how we can reduce it in our specification - and arguments about retrieving pre-existing keys specifically.

…Mark

Received on Wednesday, 28 November 2012 00:24:09 UTC