Re: [EME] Exposing key status to applications

On Fri, Sep 26, 2014 at 8:54 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> I assume myKeyId is some kinda arbitrary string, right?
>

myKeyId is probably an ArrayBuffer[View]. (However, see question #4.) I
don't know whether that affects this discussion.

>
> The best way to do that, as of today's thinking on API design, is to
> create an interface that mimics the ES Map API but doesn't provide any of
> the mutation methods.
>
> That would give you things like:
>
>   var mykeystatus = session.keys.get(myKeyId)
>

The ability to get the status for a known key ID like this seems useful.

>
> and
>
>   for (keyId of session.keys.keys())  // loops over key ids
>
> and
>
>   for (keyStatus of session.keys.values()) // loops over key statuses
>

For any type of iteration (or indexes), applications must not assume the
containers are consistent outside the current synchronous execution.

>
> The fact that two very different things are being called "keys" here is a
> bit annoying, I agree.  :(
>
> You can certainly do this all with Web IDL, though it's a pretty manual
> process to define things like keys() and values().  There are some
> proposals to doing it somewhat automagically via dedicated "make this look
> like a Map" IDL syntax, but nothing concrete there yet.
>

I was referred to this bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26183

Given that there is a general effort to do things like this, this may be
the best direction for us.

>
> The reason to do it that way instead of using direct JS property access as
> you proposed is that this will prevent issues like name collisions with
> various builtin stuff (like methods on the object itself).
>
> Whether this sort of API is best for solving your initial problem, I can't
> tell you, but if it is it's quite possible to create.
>
> -Boris
>