profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/jasnell/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.
James M Snell jasnell @cloudflare Clovis, California http://jasnell.me "I can't breathe" #46 #blacklivesmatter

jasnell/activitystrea.ms 141

Activity Streams 2.0 for Node.js (this package is not actively maintained, if you'd like to help, let me know)

Fishrock123/bob 73

🚰 binary data "streams+" via data producers, data consumers, and pull flow.

jasnell/awaitable-timers 21

Polyfill of Node.js awaitable timers

davidmarkclements/proffer 12

Realtime V8 Tick Profiler

jasnell/activitystreams 5

Activity Streams 2.0 Java Reference Implementation

jasnell/activitystreams.jsonld 5

http://asjsonld.mybluemix.net

addaleax/node 4

Node.js JavaScript runtime :sparkles::turtle::rocket::sparkles:

jasnell/as2-schema 4

activitystrea.ms schema.org extensions

issue commentjasnell/sockets-api

Use `CryptoKey` for TLS keys

+1... absolutely agree. Representing certs is also an issue here, tho. We have an X509Certificate object in Node.js but it would be better if there were a common API. But yes, using CryptoKey makes perfect sense for this part.

lucacasonato

comment created time in a day

issue commentjasnell/sockets-api

Instead of providing a `ready` promise, use an async factory function

While I like this approach, the API pattern seems potentially less ergonomic for the server side. Specifically, in the following case: is the socket already in the ready state when the event is emitted?

addEventListener('socket', ({socket}) => {
  // is the socket already ready?
});

If it's not already in the ready state, what does the user do in the very rare cases where it might need to wait for the socket to be in a ready state before performing any actions on it (shouldn't be common at all but still worth considering...

If the socket is already in the ready state, what defines "ready" when we're talking about a TLS connection where the user-code may want to interact with the TLS handshake somehow? For instance, in Node.js' existing api there are ways to hook the client hello, providing an OCSP response, selecting a pre-shared key, etc.

lucacasonato

comment created time in a day

issue commentjasnell/sockets-api

Go all in on WHATWG streams

For the sake of discussion.... A bit of context on the why for the current design...

It's not entirely about the performance of the streams API itself, it's also about optimizing the flow of data at the underlying layers also, and for enabling support of features like 0RTT fast starts (when a protocol supports it). Passing in a payload source (the body) either in the constructor or the respondWith allows us, in various cases, to reduce the latency between when a connection is established and when the flow of data can begin. In the case of QUIC, for instance, it allows us to more efficiently support 0RTT fast-starts, where streams can be opened during the TLS handshake. It also gives us more options for data sources. That said, we could also optimize by deferring the start of the connection/handshake until the flow of data actually starts but there are other advantages to the current design.

The current design, for instance, allows us to completely bypass using a streams API entirely when all of the data can be read and transmitted more efficiently at a native layer, which is the case when using Blob or ArrayBuffer sources, or in Node.js, when using a FileHandle object. In each of these cases, using stream.writable just adds overhead that can be avoided.

// In Node.js, fs.promises.open returns a FileHandle, which allows data to be
// read efficiently entirely at the native layer, completely bypassing the streams
// APIs, and allowing the flow of data to start as soon as the connection is established.
const { open } = require('fs/promises');
cons socket = new Socket({ body: open('some_file') });

With this approach, as soon as the connection is established the file data can start to be transmitted without incurring the additional latency of calling back out to the JS layer at all. The performance boost is significant.

Also, with the current design, it's possible to achieve the same basic pattern you illustrate:

const socket = new Socket({
  body: outgoingChunks
          .pipeThrough(new TextEncoderStream())
          .pipeThrough(new CompressionStream("gzip"));
  }
});

If the use of the socket needs to be more conversational, that's possible also...

const t = new TransformStream();
cons socket = new Socket({ body: t.readable });
const reader = socket.stream().getReader();
const writer = t.writable.getWriter();

await chunk = reader.read();
await writer.write('...');

In the case where there is not going to be an outbound flow of data, or when that outbound data is already known, making that information available as soon as possible when the Socket is created allows us to optimize a number of cases.

I'm certainly not opposed to exposing a WritableStream off the Socket, and I agree with the point about API consistency, but I'd like us to try to handle:

  1. Supporting fixed data sources like strings, Blob, ArrayBufferViews, purely native layer data sources like node.js' FileHandle, etc where use of a stream API just isn't necessary.
  2. Supporting 0RTT fast starts when supported by the protocol.
  3. Supporting as early as possible indication of whether an outbound payload is even going to be provided (e.g. not having to wait until socket.writable.close() is explicitly called when we know already that we're not going to send any data.
lucacasonato

comment created time in a day

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

issue commentnodejs/node

DeprecationWarning not within node_modules?

That behavior is intentional. It was a compromise made given how extensively new Buffer() is used in dependencies.

loynoir

comment created time in a day

issue commentnodejs/node

Future of streams

@ronag ... I will be doing some benchmarking but I'm not sure exactly when I'll be getting to it. I want to go back through the impl and find optimization points that don't sacrifice spec compliance.

ronag

comment created time in 4 days

push eventjasnell/sockets-api

James M Snell

commit sha d0c05e673ba29ea3af3b0048d51cc18158069d33

Iteration

view details

push time in 4 days

push eventjasnell/sockets-api

James M Snell

commit sha 211b7270dba0688f36e7e2f51c3d80a05f380a44

Initial

view details

push time in 4 days

create barnchjasnell/sockets-api

branch : main

created branch time in 4 days

created repositoryjasnell/sockets-api

created time in 4 days

pull request commentnodejs/node

fs: add `Blob` methods to `FileHandle`

To be honest, I'm not sold on the idea of adding these methods to FileHandle at all. Alternatively, we can add FileHandle to the list of types accepted by the stream/consumers utilities, which would likely be more consistent.

aduh95

comment created time in 5 days

PullRequestReviewEvent

Pull request review commentnodejs/node

url,lib: pass urlsearchparams-constructor.any.js

 runner.setScriptModifier((obj) => {     // created via `document.createElement`. So we need to ignore them and just     // test `URL`.     obj.code = obj.code.replace(/\["url", "a", "area"\]/, '[ "url" ]');+  } else if (obj.filename.includes('urlsearchparams-constructor.any.js')) {+    // Ignore test named `URLSearchParams constructor, FormData.` because we do+    // not have `FormData`.

If we decided to add FormData later someone might miss removing this. It would be worthwhile making this replacement dependent on whether FormData is undefined.

XadillaX

comment created time in 5 days

PullRequestReviewEvent