Por que o Protobuf 3 tornou todos os campos das mensagens opcionais?

A sintaxe 3 do protobuf tornou todos os campos opcionais, descartando as palavras-chave requirede a optionalsintaxe proto2 anterior. Lendo alguns comentários dos desenvolvedores , parece que foi feito para melhorar a compatibilidade binária para frente / trás.

Mas, para mim, isso poderia ser aplicado apenas com a versão dos nomes dos pacotes, digamos com.example.messages.v1e, em seguida, permitindo que os clientes implementem desserializadores que eles entendem. Ao mesmo tempo, remove alguns contratos declarados como um tipo que são úteis do ponto de vista da engenharia de software. Por exemplo, se eu tiver

message Location {
   double latitude = 1;
   double longitude = 2;
}

No proto3, é possível criar um meio respaldo, mas perfeitamente válido Location, não fornecendo um dos campos obrigatórios.

Isso não é uma grande desvantagem ao criar um formato de serialização baseado em esquema para a troca de dados entre clientes? Não é pior mover código de validação extra para cada cliente, verificando se todos os campos obrigatórios têm valores válidos?

O proto3 faz várias alterações destinadas (como eu o entendo) a torná-lo muito mais utilizável em cenários de plataforma cruzada. O rastreamento explícito de "atribuído" vs "não atribuído, mas relatando o valor padrão" pode ser muito difícil de implementar em algumas plataformas de destino e também pode ser confuso de usar. Como tal, o proto3 adota uma abordagem muito mais simples:

• o valor padrão implícito é o valor zero natural (números / enumerações), false (booleanos) ou a string vazia (strings)
• somente o padrão implícito é permitido; nenhum outro valor padrão é permitido
• se um campo tiver esse valor padrão, ele não será serializado; não importa se foi atribuído explicitamente a zero / falso / cadeia vazia vs nunca atribuído
• por esse motivo, não há conceito de "obrigatório", pois "atribui explicitamente um valor zero" e "nunca atribuiu um valor" parecem idênticos

No proto3, é possível criar um local com meio backup, mas perfeitamente válido, não fornecendo um dos campos obrigatórios.

O outro valor é: zero. O fato de você não atribuí-lo explicitamente a zero é discutível. Se você deseja ou não isso é com você, mas faz sentido para mim e é como muitas "inicializar um novo objeto / estrutura" funcionam em uma ampla variedade de plataformas.

Não é pior mover código de validação extra para cada cliente, verificando se todos os campos obrigatórios têm valores válidos?

Não há nada para validar! O layout é exatamente o que seria se o valor zero fosse atribuído explicitamente. Se isso é legal, é legal. Se é ilegal (porque zero não faz sentido para você), é ilegal; mas seria ilegal se fosse explícito ou implícito. A quantidade de validação envolvida não muda.

Isso não é uma grande desvantagem ao criar um formato de serialização baseado em esquema para a troca de dados entre clientes?

Geralmente não, não ... especialmente porque a versão do esquema é explícita. Se você deseja usar proto2: use proto2. Nada muda automaticamente.