domenic

Proposed ARIA API

I propose adding an implicitAria property to all elements that exposes and allows modification of their implicit ARIA roles, states and properties, i.e. the values that are used when no HTML attributes are present to override them. "No role" manifests as null in JavaScript.

In what follows, let el.[[role]] and el.[[aria-expanded]] and the like be a fictional syntax for getting the screen-reader exposed ARIA values for an element. We could consider, as a separate proposal, exposing an API for these.

Examples with Normal Elements

HTMLHRElement

domenic

Received: from CY1PR0501MB1483.namprd05.prod.outlook.com (25.160.149.144) by
 BY1PR0501MB1477.namprd05.prod.outlook.com (25.160.108.141) with Microsoft
 SMTP Server (TLS) id 15.0.1049.19 via Mailbox Transport; Mon, 13 Oct 2014
 04:48:45 +0000
Received: from BL2PR05CA0017.namprd05.prod.outlook.com (10.255.226.17) by
 CY1PR0501MB1483.namprd05.prod.outlook.com (25.160.149.144) with Microsoft
 SMTP Server (TLS) id 15.0.1049.19; Mon, 13 Oct 2014 04:48:41 +0000
Received: from BY2FFO11FD006.protection.gbl (2a01:111:f400:7c0c::176) by
 BL2PR05CA0017.outlook.office365.com (2a01:111:e400:c04::17) with Microsoft
 SMTP Server (TLS) id 15.0.1049.19 via Frontend Transport; Mon, 13 Oct 2014

domenic

abstract operation: ReadFromReadableStream(stream) contains most of what we have now.

ReadableStreamLock class

Has a [[stream]] internal slot.

Present as an intrinsic named %ReadableStreamLock%.

new ReadableStreamLock(stream)

domenic

Inspired by whatwg/streams#253 (comment), but way updated

Use cases:

• (all) Want to read a 10 MiB file into a single ArrayBuffer
• (chunkwise) Want to read a 10 MiB file, 1 MiB at a time, re-using a single 1 MiB ArrayBuffer, and calling processChunk on each chunk before reading the next one
• (ping-pong) Want to read a 10 MiB file, 1 MiB at a time, re-using two separate 1 MiB ArrayBuffers, because you are asynchronously processing (processChunk) the 1 MiB chunks and want to get a potential 1 MiB headstart in parallel with the async processing

Note: we're using ES2016 async/await syntax so that we don't have to do recursion with promises but instead can just use loops. This shouldn't really bias the comparison as all of these designs involve the same amount of promises.

domenic

Async ReadInto Is a Problem

The overriding design goal of ReadableByteStream---likely above all others---is to enable zero-copy reading from underlying sources. (Well, OK, maybe we'll need one copy from kernel space to user space.)

As we've discovered, there are essentially two forms in which underlying source APIs are provided:

• The read(2) form: based on read(2). Can be modeled as (buffer, offsetIntoBuffer, desiredBytes) -> bytesRead. This call is synchronous and so will take place in a threadpool (important!). Another thread can observe the buffer filling up with data until the fread call returns.

• The epoll form: based on epoll(7)/.... TODO explain more and talk more about epoll later insteadof just read(2).

domenic

File streams

According to libuv folks, the most reliable way to do asynchronous file I/O is blocking read(2) in a threadpool. Although Windows has IO Completion Ports, they fall down in enough cases they are largely not used. Regardless, we want to support read(2)-in-a-threadpool models, so this section assumes files are a good instantiation of that model, and analyzes how readable byte streams work in that case.

Reading a file byte stream into an ArrayBuffer

Given a file readable byte stream with a known size, read the entire thing into memory:

async function file_exact(fileRBS, knownFileSize) {

domenic

interface PermissionStatus : EventTarget {
    readonly attribute PermissionState status;
             attribute EventHandler onchange;
};

interface Permissions {
    readonly attribute GeolocationPermission geolocation;
    readonly attribute MidiPermission midi;
    readonly attribute NotificationsPermission notifications;
    readonly attribute PushPermission push;

domenic

// Run processFn on each chunk, while only ever allocating maxChunkSize * 2
// memory, and never causing GC (by reusing the same backing buffers)
// Is able to do a read in parallel with the async processFn operation!
async function processPingPong(rbs, maxChunkSize, processFn) {
  const reader = rbs.getByobReader();
  const pool = [new Uint8Array(maxChunkSize), new Uint8Array(maxChunkSize)];
  
  let i = 0;
  let toProcess;
  await doRead(0);

domenic

<template>
  <style>
    #label {
      background: var(--nametag-background);
    }
    #name {
      @extend %nametag-name;
    }
  </style>
  

domenic

"use strict";
var kDefaultBacktraceLength=10;
var Debug={};
var sourceLineBeginningSkip=/^(?:\s*(?:\/\*.*?\*\/)*)*/;
Debug.DebugEvent={Break:1,
Exception:2,
NewFunction:3,
BeforeCompile:4,
AfterCompile:5,