Since this is largely about size efficiency we will only define this splitting for binary forms (not WAT).
Design goals:
TBD: preamble layer "split" bit
Taking binary Wasm as input:
Digest calculation is a variation of the split algorithm which requires all possible (recursive) section splits to be performed. Split contents do not need to be stored, just included in recursive digest calculations.
Taking binary Wasm as input:
Content is hashed using a supported hash algorithm to produce a content digest. This is encoded along with an identifier of the hash algorithm:
For split sections with optional splitting of inner sections/segments, the typeddigest
must be computed "as if" all allowed splitting has been done.
Split section ID (
X
) TBD; should be reserved in component and core specs
sectionid
and sectionsize
record the original section's id and sizecustomname
is copied from the original custom section's name
datasegmentsplitopt
allows a splitting implementation to leave a data segment inline (segmentdata
) but may not be used when calculating digests for the parent core module.segmentheader
records the original data segment's "header": the segment type and any other fields that come before the actual segment's data. This allows the splice algorithm to mechanically reconstruct segments without "knowing" about segment typessegmentdatasize
and segmentdatadigest
record the original segment data's size and digestYou could think of "split" Wasm as just another kind of binary Wasm with particular features, in which case it could be covered by the existing application/wasm
type. However, it may be useful to allow consumers to differentiate between "split" and "unsplit" forms. We could specify a separate type (e.g. application/split+wasm
) or a parameter (e.g. application/wasm; split=1
) to distinguish between them.