2016-04-20 12 views
5

Devo inviare messaggi a un'altra squadra utilizzando la versione proto2 di Google Protocol Buffers. Stanno usando Java e C++ su Linux. Sto usando C# su Windows.Proto2 vs. Proto3 in C#

La porta protobuf-csharp di Jon Skeet (https://github.com/jskeet/protobuf-csharp-port) supporta proto2. Se ho capito bene, Google ha preso questo codice e ne ha piegato una versione aggiornata nel progetto protobuf principale (https://github.com/google/protobuf/tree/master/csharp). Ma non supporta più proto2 per C#, solo proto3.

Non sono sicuro di quale progetto dovrei utilizzare. Sembra che il nuovo sarà meglio supportato (prestazioni, supporto per proto3 se l'altro team aggiornerà mai). Ma dovrei convertire il file .proto che mi è stato dato da proto2 a proto3 e correre il rischio che si verifichino problemi.

Ho letto che per la maggior parte, i messaggi per proto2 e proto3 sono compatibili. Non ho esperienza con i Protocol Buffers, ma il file .proto con cui sto lavorando sembra piuttosto vanilla, nessun valore predefinito o nulla o nested. Sembra quindi che potrei cancellare solo le parole chiave "richieste" e "facoltative" e utilizzare la nuova libreria, trattandola come un file proto3.

Secondo la tua opinione, vale la pena usare la nuova libreria? Esiste un elenco di caratteristiche di proto che renderebbero incompatibili i messaggi proto2 e proto3?

risposta

8

Se l'altra squadra ha campi obbligatori e si inviano messaggi senza specificare tali campi (o anche specificando esplicitamente il valore predefinito, per le primitive), l'altra estremità non riceverà i messaggi - non verranno convalidati .

Ci sono varie differenze tra proto2 e proto3 - alcuni sono elencati sul releases page:

Di seguito sono le principali novità in lingua versione 3:

  • rimozione della logica campo presenza per campi di valori primitivi, rimozione dei campi obbligatori e rimozione dei valori predefiniti. Ciò rende Proto3 molto più facile da implementare con le rappresentazioni di struct aperte, come in lingue come Android Java, Objective C o Go.
  • Rimozione di campi sconosciuti.
  • Rimozione di estensioni, che vengono invece sostituite da un nuovo tipo standard denominato Any.
  • Risolviente semantica per valori enum sconosciuti.
  • Aggiunta di mappe.
  • Aggiunta di un piccolo insieme di tipi standard per la rappresentazione di tempo, dati dinamici, ecc.
  • Una codifica ben definita in JSON come alternativa alla codifica protobinario binaria.

La rimozione di campi sconosciuti potrebbe essere un problema significativo per voi - se l'altra squadra si aspetta di essere in grado di inviare un messaggio con alcuni campi il codice è a conoscenza, e essere in grado di restituire un messaggio a loro che mantengono quei campi, proto3 potrebbe porre problemi per te.

Se si può utilizzare proto3, suggerirei di utilizzare la versione proto3, in parte perché avrà il supporto adeguato mentre la versione proto2 è fondamentalmente in modalità di manutenzione.Esistono differenze significative tra i due, principalmente in termini di mutabilità: le classi di messaggi generate nella base di codice proto3 sono mutabili, il che è ottimo per l'usabilità immediata, ma può porre sfide in altre aree.

+1

non riesco ancora a credere di aver eliminato le impostazioni predefinite :( –

+0

La guida linguistica per [proto2] (https://developers.google.com/protocol-buffers/docs/proto) elenca le mappe come supportate. provato a utilizzare il proto compilatore 3 con [proto3] (https://developers.google.com/protocol-buffers/docs/proto3#default) e sembra ignorare i campi impostati con valori predefiniti (int con 0 è stato rimosso da binary e json rappresentazione) – Manoj

+0

@Manoj: Penso che fossero supportati in una certa misura, ma non da tutte le lingue, e probabilmente con una semantica leggermente diversa. Non sono sicuro di cosa intendi per "sembra ignorare i campi impostati con valori predefiniti". significa semplicemente "il valore 0 non è serializzato", hai ragione, –