¿Por qué Protobuf 3 hizo todos los campos en los mensajes opcionales?

La sintaxis 3 de protobuf hizo que todos los campos fueran opcionales eliminando las palabras clave requiredy optionalde la sintaxis proto2 anterior. Al leer algunos comentarios de los desarrolladores , parece que se hizo para mejorar la compatibilidad binaria hacia adelante / hacia atrás.

Pero para mí, eso podría hacerse cumplir simplemente versionando los nombres de los paquetes, digamos com.example.messages.v1y luego permitiendo que los clientes implementen deserializadores que entiendan. Al mismo tiempo, elimina algunos contratos establecidos como un tipo que son útiles desde el punto de vista de la ingeniería de software. Por ejemplo si tengo

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

En proto3 es posible crear un medio respaldado pero perfectamente válido Locational no proporcionar uno de los campos obligatorios.

¿No es un gran inconveniente al crear un formato de serialización basado en esquemas para el intercambio de datos entre clientes? ¿No es peor mover el código de validación adicional a cada cliente comprobando que todos los campos obligatorios tienen valores válidos?

proto3 realiza una serie de cambios destinados (según tengo entendido) a hacer que sea mucho más utilizable en escenarios multiplataforma. El seguimiento explícito de "asignado" frente a "no asignado pero que informa el valor predeterminado" puede ser muy difícil de implementar en algunas de las plataformas de destino, y también puede ser confuso de usar. Como tal, proto3 adopta un enfoque mucho más simple:

• el valor predeterminado implícito es el valor cero natural (números / enumeraciones), falso (booleanos) o la cadena vacía (cadenas)
• solo se permite el valor predeterminado implícito; no se permiten otros valores predeterminados
• si un campo tiene ese valor predeterminado, no se serializa; no importa si fue asignado explícitamente a cero / falso / cadena vacía versus nunca asignado
• debido a esto, no existe el concepto de "requerido", ya que "se le asignó explícitamente un valor cero" y "nunca se le asignó un valor" parece idéntico

En proto3 es posible crear una ubicación con respaldo medio pero perfectamente válida al no proporcionar uno de los campos obligatorios.

El otro valor es: cero. El hecho de que no lo haya asignado explícitamente a cero es discutible. Depende de usted si esto es deseable o no, pero tiene sentido para mí y es cómo funciona una gran cantidad de "inicializar un nuevo objeto / estructura" en una amplia gama de plataformas.

¿No es peor mover el código de validación adicional a cada cliente comprobando que todos los campos obligatorios tienen valores válidos?

¡No hay nada que validar! El diseño es exactamente lo que sería si el valor cero se asignara explícitamente. Si eso es legal, es legal. Si es ilegal (porque cero no tiene sentido para usted), es ilegal; pero sería ilegal si fuera explícito o implícito. La cantidad de validación involucrada no cambia.

¿No es un gran inconveniente al crear un formato de serialización basado en esquemas para el intercambio de datos entre clientes?

Por lo general, no, no ... especialmente porque la versión del esquema es explícita. Si desea usar proto2: use proto2. Nada cambia automáticamente.