On 2013-04-01 19:13, Jesse Phillips wrote:

Let me see if I can describe this.

PB does encoding to binary by type. However it also has a schema in a
.proto file. My first concern is that this file provides the ID to use
for each field, while arbitrary the ID must be what is specified.

The second one I'm concerned with is option to pack repeated fields. I'm
not sure the specifics for this encoding, but I imagine some compression.

This is why I think I'd have to implement my own Serializer to be able
to support PB, but also believe we could have a binary format based on
PB (which maybe it would be possible to create a schema of Orange
generated data, but it would be hard to generate data for a specific
schema).

As I understand it there's a "schema definition", that is the .proto file. You compile this schema to produce D/C++/Java/whatever code that contains structs/classes with methods/fields that matches this schema.

If you need to change the schema, besides adding optional fields, you need to recompile the schema to produce new code, right?

If you have a D class/struct that matches this schema (regardless if it's auto generated from the schema or manually created) with actual instance variables for the fields I think it would be possible to (de)serialize into the binary PB format using Orange.

Then there's the issue of the options supported by PB like optional fields and pack repeated fields (which I don't know what it means).

It seems PB is dependent on the order of the fields so that won't be a problem. Just disregard the "key" that is passed to the archive and deserialize the next type that is expected. Maybe you could use the schema to do some extra validations.

Although, I don't know how PB handles multiple references to the same value.

Looking at this:

https://developers.google.com/protocol-buffers/docs/overview

Below "Why not just use XML?", they both mention a text format (not to be confused with the schema, .proto) and a binary format. Although the text format seems to be mostly for debugging.

--
/Jacob Carlborg

Reply via email to