DrftStream

class DrftStream

import { DrftStream } from '@driftengine/drft';

In depth

Its own entry point rather than a flag on readDrft, which is what docs/FORMAT.md §4.6 asks for and the reason is the strictness. readDrft requires a HEAD and at least one MESH and refuses anything partial, which is right for a file on disk and wrong for a stream. The rules do not relax here, they move: a chunk is validated when its last byte lands, the table's own rules apply the moment the table is readable, and the whole-asset rules apply at end. A malformed file still throws, naming the chunk.

Zero-copy survives, and that is not obvious. The header carries totalBytes, so this allocates one buffer of the final size the moment it knows that number and writes arriving bytes into it. Every completed chunk is then viewed in place, exactly as a whole-file read views it. Accumulating chunks into their own buffers instead would cost a copy per chunk and give up the one property this format exists for.

Sequential, because that is the property worth designing for: with the payloads laid out in priority order by the baker, a plain fetch refines the model as bytes arrive, with no range requests and no server support beyond serving a file. Range requests would be an optimisation on top, and would need an offset per push rather than a different reader.

Constructor

constructor(handlers?: DrftStreamHandlers)

Accessors

Methods

push(part: Uint8Array): void

end(): void