Re: Mutability of CryptoOperationData

On Fri, Oct 25, 2013 at 11:05 PM, Alexey Proskuryakov <ap@webkit.org> wrote:

>
> 25 окт. 2013 г., в 22:51, Ryan Sleevi <sleevi@google.com> написал(а):
>
> I dislike having to have side effects on the inputs, especially since
> sequence is defined to make a copy (as opposed to array).
>
> This implies copy/copy-on-write already, per WebIDL, unless I'm
> incorrectly interpreting the sequence semantics.
>
> I think that the sequence itself is copied, but it’s not a deep copy. So
> no, the spec currently doesn’t resolve issues caused by mutability of
> ArrayBuffers.
>

Good point. Looking through
http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence , it does appear simply
to suggest the Sequence itself is copied.


> Suggesting copy on write would be somewhat unprecedented I think. I don’t
> have a strong opinion about copy on write vs. freezing, but I imagine that
> TC39 folks may have such.
>
> - WBR, Alexey Proskuryakov
>
>
Spec wise, I think the goal should be to permit any number of possible
internal implementations, provided the external behaviour remains
consistent. The 'expected' external behaviour is that the operation acts
upon the data present in the CryptoOperationData at the time of the call.
This would be specified by describing the normative-equivalent operation as
taking a copy of all the data during the call - eg: by invoking Structured
Clone and then freezing the structured clone (but *not* neutering or
freezing the original). Implementations could then implement COW w/o
violating that normative guarantee.

The only place I'm aware of where a spec mutates the input would be the
MessagePort case for Transferrables. Is the pattern of freezing the input
common? And have I misread ES6, but is there a way to go from frozen to
unfrozen? It seems SetIntegrityLevel only supports going to sealed or
frozen, and never back.