New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change WebAssembly module file signature #928

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
4 participants
@qwertie

qwertie commented Dec 22, 2016

Changes the file signature in BinaryEncoding.md as suggested in #921. This PR also increments the version number to 0xE so that we can talk about 0xE as a shorthand way of to referring to this change, but to minimize disruption, module readers can continue to accept the old signature in addition to the new one.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Jan 31, 2017

It looks highly unlikely that there is going to be one compatible wasm encoding due to the difficulty in getting agreement across web browser vendors and perhaps it was not a health expectation anyway.

So perhaps a single version is not the best approach moving forward, perhaps files need to be tagged somewhat like the 'User-Agent' header in HTTP requests with the features that are used by the wasm file.

This might allow different opcode tables for different vendors. Even if they had some cross compatibility support they might have a preferred ordering (for example there could the google-block and the moz-block operators with different unreachable code semantics etc).

The user layer translator would be responsible for generating code suitable for the target web browser and it could fill in the features used in the wasm file header which might also be input into cache keys. For example, if local variables are not used then this feature could just not be listed in the header and it would be a validation error if it were used and an opcode table without these opcodes might be chosen.

So perhaps changing the header could be deferred until a little more is sorted out.

ghost commented Jan 31, 2017

It looks highly unlikely that there is going to be one compatible wasm encoding due to the difficulty in getting agreement across web browser vendors and perhaps it was not a health expectation anyway.

So perhaps a single version is not the best approach moving forward, perhaps files need to be tagged somewhat like the 'User-Agent' header in HTTP requests with the features that are used by the wasm file.

This might allow different opcode tables for different vendors. Even if they had some cross compatibility support they might have a preferred ordering (for example there could the google-block and the moz-block operators with different unreachable code semantics etc).

The user layer translator would be responsible for generating code suitable for the target web browser and it could fill in the features used in the wasm file header which might also be input into cache keys. For example, if local variables are not used then this feature could just not be listed in the header and it would be a validation error if it were used and an opcode table without these opcodes might be chosen.

So perhaps changing the header could be deferred until a little more is sorted out.

@RyanLamansky

This comment has been minimized.

Show comment
Hide comment
@RyanLamansky

RyanLamansky Feb 1, 2017

@Wllang I passionately hope that never happens.

RyanLamansky commented Feb 1, 2017

@Wllang I passionately hope that never happens.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 1, 2017

@Kardax Without room for variation and experimentation I expect there will be very slow and difficult improvement. Sometimes you have to give a little to get something good back, and the web community can give the vendors some freedom here by implementing a translation stage that targets the vendors features and in return we get to take advantage of those improvements and fill otherwise. What we need from the vendors is a description of features so we can target them clearly and good support for a translation stage. I don't object to this PR if that is what the vendors can agree on, but I could live without it and even different headers for each vendor.

ghost commented Feb 1, 2017

@Kardax Without room for variation and experimentation I expect there will be very slow and difficult improvement. Sometimes you have to give a little to get something good back, and the web community can give the vendors some freedom here by implementing a translation stage that targets the vendors features and in return we get to take advantage of those improvements and fill otherwise. What we need from the vendors is a description of features so we can target them clearly and good support for a translation stage. I don't object to this PR if that is what the vendors can agree on, but I could live without it and even different headers for each vendor.

@sunfishcode

This comment has been minimized.

Show comment
Hide comment
@sunfishcode

sunfishcode Feb 1, 2017

Member

@Wllang This PR proposes changing the wasm binary format header to support the List-Of-Sections idea. This idea is independent of whether the binary format should also have other features (even if those features would want additional changes to the header). For new topics of discussion, please file new issues.

Member

sunfishcode commented Feb 1, 2017

@Wllang This PR proposes changing the wasm binary format header to support the List-Of-Sections idea. This idea is independent of whether the binary format should also have other features (even if those features would want additional changes to the header). For new topics of discussion, please file new issues.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Feb 1, 2017

@sunfishcode It does still include a single version number and that was what I was drawing attention to which is not going to cut it if web browser vendors have different well versions, and it bakes in a fixed size of 6, but sure it could be further modified as necessary, enough said.

ghost commented Feb 1, 2017

@sunfishcode It does still include a single version number and that was what I was drawing attention to which is not going to cut it if web browser vendors have different well versions, and it bakes in a fixed size of 6, but sure it could be further modified as necessary, enough said.

@jfbastien

This comment has been minimized.

Show comment
Hide comment
@jfbastien

jfbastien May 12, 2017

Member

This is now obsolete and can't be changed since Firefox and Chrome are shipping WebAssembly.

Member

jfbastien commented May 12, 2017

This is now obsolete and can't be changed since Firefox and Chrome are shipping WebAssembly.

@jfbastien jfbastien closed this May 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment