Re: WebIDL usage for Algorithms

I haven't reviewed the proposed language, but as expressed to you in email,
I agree it needs to change from Algorithm into a more opaque type to
support such an action.

I don't think we can use prose to wipe away a normative reference to WebIDL.
On Mar 10, 2014 7:13 PM, "Mark Watson" <watsonm@netflix.com> wrote:

>
>
> Sent from my iPhone
>
> On Mar 10, 2014, at 6:39 PM, Richard Barnes <rlb@ipv.sx> wrote:
>
> So it seems like the editors' inclination (and what's in WebKit/Chrome) is
> option (1), requiring custom bindings.  I can agree with that, and
> understand the utility of still having the dictionaries around in that case.
>
> It still seems like we need to change the use of Algorithm in the
> SubtleCrypto methods to prevent binding at that method invocation.
>
>
> We have text that says the type mapping doesn't happen on method
> invocation but when explicitly stated in the asynchronous part. Do you
> think we need more ?
>
> ...Mark
>
>
> --Richard
>
>
>
> On Mon, Mar 10, 2014 at 11:50 PM, Mark Watson <watsonm@netflix.com> wrote:
>
>> Richard,
>>
>> Yes, Ryan and I discussed this and I've proposed a solution in the ED.
>>
>> First, since we decided all errors must be asynchronous, we can't have
>> WebIDL type mapping happening at the usual time. We explicitly note this
>> and then explicitly specify when to do type mapping. The type mapping is
>> done in the "normalize to X" algorithm which takes an object and does
>> WebIDL type mapping to dictionary type X (as well as resolving any aliases,
>> though we still don't have any of these defined).
>>
>> As you say, this mapping discards members not mentioned in X, so
>> "normalize to Algorithm" leaves you only with name. The individual
>> algorithm operations call "normalize to Y" where Y is the appropriate
>> subclass.
>>
>> ...Mark
>>
>>
>> On Mon, Mar 10, 2014 at 4:18 PM, Ryan Sleevi <sleevi@google.com> wrote:
>>
>>>
>>> On Mar 10, 2014 4:12 PM, "Richard Barnes" <rlb@ipv.sx> wrote:
>>> >
>>> > TL;DR: Usage of Dictionary inheritance for Algorithms is broken.
>>>  Should use WebIDL object type or callback interfaces instead.
>>> >
>>> > BACKGROUND:
>>> > In the current spec, algorithm identifiers and parameters are passed
>>> to encrypt(), decrypt(), etc. using dictionaries that inherit from
>>> Algorithm, which is itself a dictionary type.  For example:
>>> >   dictionary Algorithm { DOMString name; }
>>> >   dictionary AesCbcParams : Algorithm { CryptoOperationData iv; }
>>> >   typedef (Algorithm or DOMString) AlgorithmIdentifier;
>>> >   Promise<any> encrypt(AlgorithmIdentifier algorithm, ... )
>>> >
>>> > PROBLEM:
>>> > According to the WebIDL spec for handling of dictionary types, the
>>> implementation is required to create the dictionary object by copying out
>>> of the source object the fields specified in the type definition.
>>> > http://www.w3.org/TR/WebIDL/#es-dictionary
>>> >
>>>
>>> Yes, I raised this privately with Mark when discussing things I didn't
>>> think were LC ready.
>>>
>>> > For WebCrypto, this means that polymorphism via inheritance of
>>> dictionaries doesn't work.  If someone creates a dictionary that matches
>>> AesCbcParams and passes it to encrypt(), then the WebIDL implementation
>>> will only store the "name" field, and throw everything else away.  Anything
>>> using the WebIDL object will not be able to see the "iv" parameter.
>>> >
>>>
>>> Did the wording Mark proposed to handle this not address it?
>>>
>>> Note the asynchronous behavior of WebIDL conversions that are written.
>>>
>>> > As far as implementation: I discovered this bug while trying to
>>> implement using the Firefox WebIDL implementation, so clearly Firefox has
>>> this problem :)  It appears that Chromium is internally treating
>>> "algorithm" arguments as generic objects (not following the WebIDL spec for
>>> dictionaries), then using a "parseAlgorithm" method to pull out relevant
>>> information.
>>> >
>>>
>>> Both Blink and WebKit have implemented this with custom bindings.
>>>
>>> > PROPOSED RESOLUTION:
>>> > It seems to me that we have a couple of options here.
>>> >
>>> > 1. "typedef object Algorithm" - Don't have the WebIDL handle any of
>>> the internal structure of Algorithm objects, but instead lay this out in
>>> the text of the spec.  In this case, there's no inheritance to speak of,
>>> just lists of what parameters must be present in each use of Algorithm.  We
>>> would need to specify at what point in the process values are extracted
>>> from the object.
>>> >
>>>
>>> Or just call it "any"
>>>
>>> > 2. "callback interface Algorithm" - This would use inheritance and
>>> have the expected behavior, since callback interfaces keep around a copy of
>>> the provided JS object.  However, there might be some weird behaviors if
>>> people pass in exotic objects, e.g., side-effects or changing values.
>>>  Also, the spec would need to carefully define exactly when the properties
>>> are accessed, and all per-spec access to the properties would need to be
>>> done on the main thread, since it needs to be able to run script.
>>> >
>>>
>>> Strongly opposed to this. Its going to be quite ugly and requires
>>> painting over all of the ES5/ES6 interactions.
>>>
>>> > I have a slight preference for (2).  It continues to delegate most of
>>> the work to WebIDL, and it seems unlikely that people will do exotic enough
>>> things to cause trouble, given that the way WebCrypto uses these objects is
>>> fairly straightforward.
>>> >
>>> > --Richard
>>> >
>>> >
>>>
>>> Considering that the WebIDL spec changed in order to support other use
>>> cases of ours - notably, the Promise<resolve type> notation - have you
>>> considered approaching the WebIDL WG with this?
>>>
>>> >
>>> >
>>> >
>>> >
>>>
>>
>>
>