Re: On optionality

On Tue, Nov 27, 2012 at 4:23 PM, Mark Watson <watsonm@netflix.com> wrote:
> 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.

And in the realm of DAP, in the realm of WHATWG, and in the realm of
WEBAPPS, there is a common pattern for this:

navigator.foo

This allows trivial detection of a feature:

var foo = navigator.foo;
if (foo == undefined) {
  // not supported
}

A reduced example of this can be seen in [GAMEPAD], which should be a
minimal spec for perusing.

In some cases with WHATWG (and to a lesser degree, whatever HTMLWG has
copied from the Living Standard in WHATWG), this may show up with
explicit methods for gaining a specific context or determining support
for it.

For example, from [CANVAS]

var foo = canvas.getContext('webgl', ...);
// var foo now contains a WebGLRenderingContext

>
> 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.

No, the API contract proposed **is** "Any DoSomething(Any, ...)" -
simply relying on textual descriptions of possible values for "any".
This is the exact same, from a programmers perspective, as "void*
dosomething(void*, void*)". The fact that a cast occurs within the
function itself is irrelevant from the perspective of any developer
who is using this API. They cannot infer the expected types,
arguments, or parameters. They cannot have any reliable guarantee on
the error mode when things fail. Nor can they even proactively
determine if something is supported, not implemented, broken,
whatever.

When we talk about device specific features, the end-user/developer
needs to be at the forefront. They need to be able to easily detect if
a feature is available. Whether this is
"canvas.supportsContext('webgl')" or
"navigator.{gamepad,battery,device}", it provides concrete objects and
interfaces that can be used by developers, with strong guarantees
enforced not by prose, but by the interface itself.

>
> 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.

I strongly believe the two issues are orthogonal, as expressed before.
The needs for algorithms and the needs for key discovery, while
similar conceptually similar, do not require nor necessarily benefit
from shared paradigms.

As one specific example, key discovery is dependent on the UA the the
parameters, whereas any cryptographic operation, it's dependent on the
UA, the parameters, and the key object itself (and its
implementation). It is this latter fact that resulted in the proposed
API, which itself absolutely needs improvement and/or reworking.

>
> 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.

As shown in DAP, as shown in WHATWG, as shown in WEBAPPS, the approach
for such optionality has been accomplished by separate specifications.

Consider, for example, the Core Device interface [CORE-DEVICE], which
is then extended by various specs [MESSAGING-API]. Or consider Web
Intents, which defines a core API but *does not* specify what or how
the intent should behave. Instead, that's left for specs like
[PICK-MEDIA] or [CONTACTS].

As you can see, the web platform already has a number of ways to deal
with this, and we arguably should not go create yet another one.

I agree with your sentiment - we do not want further optionality.
However, as you can see by the numerous examples I've provided,
optionality has been approached by saying that implementers MUST
implement every part of the interface, and defining that interface in
an independent specification (GAMEPAD, CORE-DEVICE, MESSAGING-API). If
a U-A doesn't implement the spec, obviously they don't implement the
interface either, and developers can easily discover this.

In the few cases where extensible APIs are provided (CANVAS,
WEB-INTENTS), the primary spec merely notes the normative behaviour of
the extensible API, and it's up to some other spec to define how that
extensible API behaves [WEBGL, PICK-MEDIA, CONTACTS].

Note that even in the case of something like [CANVAS], where the
context is an extensible string identifier (arguably similar in
concept, but not at all in implementation, to AlgorithmIdentifier),
there still exists the fundamental means to query support, with as
limited information as possible, from a user agent [CANVAS-SUPPORTS]

This is even true for APIs with double discoverability (CANVAS ->
WEBGL, WEBGL -> WEBGL-EXTENSION), which exposes a DOM-friendly
discovery API (getSupportedExtensions), which uses a separate registry
[WEBGL-REGISTRY], and which uses concrete interface types with
submethods for extension (eg: [DEBUG-SHADERS]).

As such, as stand by my objections to the previous proposal from Netflix:
  * The core spec (as to be implemented by all user agents) does not
need to and should not reference features that are not universally
implementable, beyond acknowledging they may exist. Arguably, this
argument could (and eventually will have to) extend to Algorithms as
well.
  * Extensibility of the DOM has historically been accomplished by
providing concrete interfaces with concrete methods, easily queried by
developers (to see if a user agent supports it), with as strict a type
enforcement as possible (eg: methods with concrete signatures)
  * APIs which are specific to a particular device class or category
(such as [VIBRATION, BATTERY, LIGHTS, NETINFO, GAMEPAD]) have
traditionally been incorporated within secondary specifications and
semi-independent timelines.

My broader objections regarding "generic" key discovery are this.
There are many needs for key discovery beyond the pre-provisioned ID
case (for example, certificate based discovery). If we're going to
propose a generic interface, then we MUST follow the "rule of three"
of software design - discussing *at least* three discovery methods to
make sure our API is actually going to be suitable for all them and
behave in an expected way - for the web platform and for developers.

This is why I speced out so many algorithms - to try and enumerate the
many different types and requirements (for example, GCM's
authentication tag, PBKDF2's password input, DH's key agreement, HMAC
verification), so that we can actually compare and contrast the API
and its semantics. And these were "simple" exactly because it's
universally agreed upon what the "RSA" algorithm means - which is not
true at all for key discovery.

>
> 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
>
>
>

[GAMEPAD] http://www.w3.org/TR/gamepad/#navigator-interface-extension
[CANVAS] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-canvas-getcontext
[CORE-DEVICE] http://dev.w3.org/2009/dap/device/
[MESSAGING-API] http://www.w3.org/TR/messaging-api/
[WEB-INTENTS] http://www.w3.org/TR/web-intents/
[PICK-MEDIA] http://www.w3.org/TR/gallery/
[CONTACTS] http://www.w3.org/TR/contacts-api/
[CANVAS-SUPPORTS]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-canvas-supportscontext
[LIGHTS] http://www.w3.org/TR/ambient-light/
[VIBRATION] http://www.w3.org/TR/vibration/
[NETINFO] http://www.w3.org/TR/netinfo-api/
[BATTERY] http://www.w3.org/TR/battery-status/
[WEBGL] http://www.khronos.org/registry/webgl/specs/latest/
[WEBGL-EXTENSION] http://www.khronos.org/registry/webgl/specs/latest/#5.14.14 /
[WEBGL-REGISTRY] http://www.khronos.org/registry/webgl/extensions/
[DEBUG-SHADERS]
http://www.khronos.org/registry/webgl/extensions/WEBGL_debug_shaders/

Received on Wednesday, 28 November 2012 01:51:14 UTC