Design: Registre .wasm como aplicativo / wasm em www.iana.org

Acredito que @flagxor fez isso no ano passado: https://github.com/WebAssembly/meetings/blob/f6705a7fc135271700ff1fb5d1ca0637893723bf/2017/WG-10-23.md#mime -type-for-wasm

Também foi discutido aqui: https://github.com/WebAssembly/spec/issues/583

@jfbastien Obrigado pela informação. Eu li essa nota reunião (e que seção particular) quando foi publicado no Github, mas eu esqueci completamente sobre ele até que você ressurgiu-lo.

Qual é o status atual do registro?

Oi! Alguma atualização sobre como adicionar arquivos .wasm à IANA?

Não acompanhei este tópico de perto, mas parece que o status atual é este:

application/wasm foi adicionado ao registro de tipo de mídia padrão provisório .

O processo para registros provisórios é descrito em rfc6838 aqui . O processo w3 é descrito aqui: Registre um tipo de mídia da Internet para uma especificação W3C .

Parece que, para avançar o processo, teremos que prosseguir para a Recomendação do candidato com a especificação WebAssembly. @ericprud : precisamos fazer mais alguma coisa antes disso?

Não tenho certeza de onde a seção de registro, conforme descrito na etapa 2 do processo w3, está localizada. @flagxor você tem uma cópia de / link para isso? Suponho que isso foi necessário para obter o status provisório.

FWIW, ele também está em vários outros bancos de dados MIME compartilhados, incluindo aquele usado pelo GitHub Pages .

Quando registrar, eu vou enviar um PR para puxar application/wasm fora de do mime-db custom-types como deveria, então, ser redundante contra iana-types . (Eu me pergunto se mime-db detectará isso por conta própria.)

Alguma atualização sobre isso? Tipos de mídia da IANA foram atualizados pela última vez em 11/07/2019

Agora que estamos no CR, podemos fazer isso a qualquer momento. Estou de férias na próxima semana. Depois disso, verei quando será a próxima reunião do W3C / IESG.

Sinta-se à vontade para me enviar um ping se eu esquecer.

Alguma atualização sobre isso? Tipos de mídia da IANA foram atualizados pela última vez em 16/10/2019

E o WAT para texto e WAB para binário?

@plehegar , podemos adicionar este registro como um apêndice ao WebAPI para que seja onde as pessoas o procurarão? Não vejo como uma mudança na especificação (a especificação prescreve application/wasm desde fevereiro de 2017 ); apenas colocando coisas em lugares previsíveis.

@todos , no modelo de registro abaixo, fui com a proposta de @verbessern para a extensão de arquivo .wab (deixando espaço para um futuro registro .wat). Existe alguma extensão de arquivo legada com a qual devemos nos conformar? Observe que mime-db usa '.wasm' . @lukewagner , qual é a sua sugestão?

Digite o nome: aplicativo
Nome do subtipo: wasm
Parâmetros exigidos: N / A
Parâmetros opcionais: N / A
Considerações de codificação: N / A (este é um formato binário)
Considerações de segurança e privacidade: consulte WebAssembly Core Security Considerations
Aplicativos que usam este tipo MIME: navegadores da web
Informações adicionais:
Número (s) mágico (s): N / A
Extensão (ões) de arquivo: .WAB
Código (s) de tipo de arquivo Macintosh: WASM
Pessoa e endereço de e-mail para contato para maiores informações: Eric Prud'hommeaux \ Uso pretendido: COMUM
Restrições de uso: nenhuma
Autor: Web Assembly Working Group do W3C.
Alterar controlador: W3C.

Parece que o emscripten também usa .wasm

A especificação WebAssembly diz .wasm :

"A extensão recomendada para arquivos contendo módulos WebAssembly em formato binário é“ .wasm ”

E, de fato, .wasm é usado em todo o ecossistema:

• ferrugem
• wabt
• binaryen
• Emscripten
• morsa
• intérprete de especificações
• Wikipedia
• Webpack
• Parcela
• Rolar
• AssemblyScript
• MDN

(Editado - adicionado mais projetos - obrigado @Pauan!)

Se isso for feito corretamente, agora é a hora, depois acabará. O .wasm obviamente é ditado pelo desejo de estender os arquivos .asm, mas as formas binárias ali são muitas (.exe, .dll, .so, ...). Os erros devem ser corrigidos, não devem ser usados ​​como base. O padrão deve ser corrigido e adequado. Haverá muitas outras implementações no futuro e incontáveis ​​arquivos à solta. Acho que ter arquivos .wasm e .wat é muito pior (eles têm até mesmo tamanhos diferentes) do que .wab e .wat. Espero que sejam formatos de arquivo muito comuns no futuro. Três letras por extensão são descritivas o suficiente.

Como será servido (MIME) é outro tópico. Não acho nenhuma razão excessiva para ser diferente de "application / wab", mas poderia ser servido como "application / web-assembly-binary" assim como "application / java-archive", por exemplo, para .jar. De forma semelhante e para o formato de texto. Essa abreviatura 'wa?' define um namespace comum para as extensões.

A existência de .wasm, não impede que haja uma "divisão" explícita para .wab e .wat, que poderia entrar nas versões subsequentes das especificações. A extensão .wasm não indica claramente a estrutura interna do arquivo, quando o binário e o formato de texto são definidos como equivalentes.

@verbessern Não acho que .wab seja uma boa ideia ou realista neste momento. .wasm já está estabelecido no ecossistema, é muito reconhecível como relacionado ao WebAssembly, e os arquivos de texto do WebAssembly serão muito raros em comparação com os arquivos binários, uma vez que os usuários finais nunca os veem e a maioria dos desenvolvedores no espaço estará trabalhando com ferramentas essa saída diretamente para arquivos binários, portanto, não parece valer a pena alterar .wasm para um paralelo mais próximo com .wat.

Isso pode ser verdade, para a quantidade de arquivos do usuário final, mas acho que isso não é um motivo, para bagunçar as extensões para .wasm e .wast (como também já está disponível por aí). Isso soa como, porque os arquivos .obj usados ​​por alguns compiladores C ++ geralmente não estão disponíveis para o usuário final, para chamá-los .asmo. Eu também não acho que .wasm seja "estabelecido". O fato de haver poucas implementações disponíveis não o torna estabelecido. Ele será estabelecido depois de muitos anos. A extensão ainda não está registrada (e por isso estamos aqui).

@sunfishcode Além disso, .wasm é usado por Webpack , Parcel e Rollup . Eu diria que está definitivamente bem estabelecido e seria muito difícil alterá-lo neste momento.

@verbessern Você parece pensar que .wasm foi escolhido porque "estende" a extensão .asm ... mas não é o caso. Foi escolhido porque "Wasm" é a abreviação oficial para "WebAssembly" (no discurso) .

É isso, essa é a razão. Seria muito estranho chamá-lo de "Wasm" na fala, mas ter a extensão de arquivo .wab , em vez da extensão de arquivo muito natural .wasm .

Além disso, .wasm sempre se refere ao formato binário , não há ambigüidade. O formato binário é o formato idiomático. O formato de texto é para depuração, e os depuradores converterão automaticamente o arquivo .wasm para o formato de texto.

É a abreviação oficial, mas tem 2 representações diferentes quando serializada, que eu acho que deve ser unificada conforme declarado acima com um prefixo comum: .wa. Não encontro uma relação forte entre o nome abreviado e a (s) extensão (ões). Eu realmente acho que o nome é influenciado pelo próprio assembly: https://en.wikipedia.org/wiki/Assembly_language , e então a extensão é mantida para descrever claramente essa relação: wasm.
Não vejo nenhum problema o suporte para web assembly ser chamado de 'suporte wasm', nem algumas bibliotecas terem módulos wasm, isso é correto, porque é assim que é abreviado. Estou falando sobre a extensão do arquivo em si, que é ambígua, longa e não se incorpora bem com a extensão do formato de texto.
O fato de poucos projetos estarem carregando uma extensão -ainda não registrada- não significa que deva ser feito em todo o mundo. Ao contrário, deve ser feito corretamente, mesmo que isso signifique ser .webasmbin / .webasmtxt.

ps. Eu também acho que os desenvolvedores tiveram que usar algo, porque trabalharam nas implementações. Isso não significa que todos quiseram ou aprovaram. Portanto, este tipo de argumento é um pouco nebuloso.

@verbessern A extensão não é ambígua (como já expliquei), 4 caracteres não é particularmente longo, corresponde ao nome de WebAssembly, sempre foi a recomendação oficial (está nas especificações ) e é amplamente utilizado por todos ferramentas.

Você parece querer tornar o formato de texto "igual" ao formato binário, mas eles não são iguais. O formato binário é o formato padrão. É o que é usado na produção. É o que é usado em mais de 99% dos usos do wasm. O formato de texto é um suplemento usado para depuração, ensino, etc. Você não deve enviar .wat arquivos. Além disso, ter .wasm e .wat separados é uma coisa boa, pois evita confusão. Torná-los mais semelhantes causa mais confusão, não menos.

Você também afirma que .wasm é, de alguma forma, "impróprio", mas não forneceu argumentos para isso. Registrar .wab não é "mais apropriado" do que registrar .wasm , isso é apenas sua preferência pessoal.

Você também continua mencionando um prefixo .wa , mas já o temos, uma vez que .wasm e .wat ambos têm um prefixo .wa . E .wasm é um formato binário de montagem, e .wat é um formato textual, então eles funcionam perfeitamente. Portanto, você realmente precisará fornecer algum tipo de argumento forte para explicar por que .wab é superior a .wasm .

A especificação WebAssembly diz .wasm :

"A extensão recomendada para arquivos contendo módulos WebAssembly em formato binário é“ .wasm ”

E, de fato, .wasm é usado em todo o ecossistema:

• ferrugem
• wabt
• binaryen
• Emscripten
• morsa
• intérprete de especificações
• Wikipedia

Sem querer fugir do tópico aqui, mas a maioria das bibliotecas no ecossistema também menciona como configurar o servidor da web para servir ao tipo MIME. Frameworks como o Spring tendem a obter sua lista de tipos de MIME de servidores da web como o Apache (embora a autoridade final seja IANA). O Apache, por outro lado, está esperando que esse problema seja resolvido https://bz.apache.org/bugzilla/show_bug.cgi?id=63162

Tudo bem. Parece que você não está lendo com atenção.

• a recomendação "oficial" está lá, porque tinha que haver alguma. O assunto ainda não foi resolvido e por isso estamos aqui.
• 4 caracteres é muito longo, com base nas extensões de 3 caracteres mais comuns.
• todas as ferramentas "existentes" não constituem um padrão, e como eu expliquei (se lidas com atenção), que a extensão "ainda não registrada" é usada, porque algumas tinham que ser, os desenvolvedores apenas seguiram o que as especificações diziam, então esse argumento não é tão forte.
• os dois formatos de serialização são equivalentes por definição, independentemente de um deles ser usado com mais frequência. Iguais com certeza não.
• Eu realmente não entendo aquele "Você não deve enviar arquivos .wat. Além disso, ter .wasm e .wat separados é uma coisa boa".
• Eu forneci muitos argumentos para oferecer suporte a arquivos .wab (se lidos com atenção): é mais curto e tem o mesmo comprimento que a extensão .wat (aliás. Na web existem arquivos .wast, não apenas .wat, então parece que você é gentil de concordar com a extensão).
• Eu realmente não tenho uma preferência pessoal, o poder que usei para discutir isso é mais do que usar uma extensão de 5 caracteres por muitos anos. Acabei de notar a falta de consistência nisso, por isso comentei. O que espero ter é lógica e um senso de consistência. E se mais pessoas tiverem a mesma "preferência pessoal" que dizem, tudo bem, do contrário também.

Posso concordar que .wasm é mais descritivo, mas é questionável que seja suficiente para uma extensão de arquivo, que quebra outras "propriedades" descritas acima. E algumas propriedades puramente cosméticas: também é mais difícil de pronunciar do que .wab.

O ponto mais importante, conforme feito por @sunfishcode , é que todas as ferramentas e documentação existentes estão usando .wasm , e mudar agora vai causar problemas que precisam ser devidamente justificados com um forte argumento de que a alternativa é significativamente melhor .

@verbessern as pessoas que discordam de sua posição não estão interpretando mal seus argumentos. Nós simplesmente não achamos que eles fazem pender a balança. Se a Web pode sobreviver a .html com 4 caracteres, então .wasm está bem com certeza.

Você fala de .wat e .wasm como sendo "dois formatos de serialização", mas este _não_ é o propósito de .wat , que existe essencialmente como uma conveniência de comunicação para humanos. Wasm _é_ uma linguagem de bytecode. O envio de .wat seria análogo ao envio de um programa Java como um arquivo de texto contendo mnemônicos de bytecode Java. Com a possível exceção de testes de conformidade de mecanismo ou tutoriais simples, as extensões .wa[s]t quase nunca devem ser vistas por alguém que não produziu o arquivo por conta própria.

Tudo bem, eu senti o desejo de contribuir para o problema com alguns argumentos. Por favor, decida o que é melhor.

ps. é que a finalidade ou não não altera o fato de serem dois formatos de serialização. Depois de definidos como equivalentes, cada um deles pode ser usado por uma implementação.
ps. Definitivamente irei refatorar um código, quando entender que as definições atuais não são apropriadas. Do contrário, a longo prazo, tudo se tornará "algo assim", mas não exatamente.

@ericprud (Desculpe pela resposta lenta.) Definitivamente concordou com @sunfishcode @ conrad-watt et al em manter .wasm como atualmente em mime-db e usado em todo o ecossistema.

@ericprud Além da extensão do arquivo, aqui estão algumas outras coisas que podemos preencher:

Aplicativos que usam este tipo MIME: navegadores da web

WebAssembly está crescendo em espaços não-Web também, então seria bom listar sistemas de tempo de execução (no sentido descrito aqui ) aqui também.

Número (s) mágico (s): N / A

O formato binário começa com os bytes 0x00 0x61 0x73 0x6D.

Com desculpas a @verbessern , parece que o consenso é que a extensão implantada é .wasm então vou enviar um PR para entrar na web-api-1.1 (ou 2? Essa é outra conversa).

@sunfishcode , acredito que você pretende este texto:

Aplicativos que usam este tipo MIME: navegadores da Web e sistemas de tempo de execução

e tx para o número mágico.

@ericprud Sim, esse texto parece bom, obrigado!