Since there extensible options are almost released, I though I would start a thread to discuss what would be interesting to support.
The current options affect the code generation trade offs for a given language: optional string java_package = 1; optional string java_outer_classname = 8; optional bool java_multiple_files = 10 [default=false]; optional OptimizeMode optimize_for = 9 [default=CODE_SIZE]; optional CType ctype = 1; Or are not to be used in current .proto files: optional bool message_set_wire_format = 1 [default=false]; optional string experimental_map_key = 9; My brainstorming at the moment produces the following language-agnostic suggestions. Note that I am not suggesting the names for any of these proposed options ( these bikesheds are unpainted ) : * FileOptions ** A "version" option that holds a string. This could be inserted into the generated code so that programs can inquire and report what version of the .proto file was used. ( Since protocol-buffers is designed to support changes in formats over time I am somewhat surprised this is not already present. ) ** Many of the MessageOptions or EnumOptions below could be set at the FileOptions level to affect all such messages or enums by default. * MessageOptions ** an option to control whether this message (by default) uses the length-prefix message format or the start/end tag group format on the wire. This would make people who prefer streaming writes over known-length writes happier. ** an option to control whether, when read from the wire format, this message should allow unknown fields or always throw an error. This might be handy to avoid much boilerplate checking for stray unknown fields. One could even make the message object slimmer if it does not not a pointer/reference to some unknown field data structure. ** an option to have the message skip unknown fields on the wire without either storing them or throwing an error. This might be handy to define "cut-down" versions of messages that skip over unwanted parts to save memory and speed up processing when loading (really querying) a large binary file. * EnumOptions ** An option to control the wire format, so it could be set to sfixed32 or sint32 by default. This would be an annoying change to support, so I probably should not have mentioned it. It makes large positive and all negative values more compact on the wire. ** An option to set the default value. The current default-default value is always the first enum value in the .proto file. * FieldOptions ** Note that the message options and enum option above may be considered to set the default behavior for the a message, but that a corresponding field option could be defined to override this for a given use of the message or enum. ( This is already possible for setting the default enum value for the field !) ** One could mark a repeated field to have a more efficient wire encoding: Write the field-id+wire-type tag only once followed by the uint32 encoded count of items (non-zero!) and then each item without any more of the tags. This would enable much more compact storage of numeric arrays. ** One could mark a repeated field to never have zero length. This might be handy to avoid much boilerplate checking for empty fields. ** One could mark an optional field to always write a value when serialized. So if it is not set it will cause the default value to be serialized into the wire stream. Hmmm.... I can't imagine how anyone would need this. * EnumValueOptions ** See the mangling suggestion below. Mangling suggestion: all but FileOptions define something with a name that might be mangled when the code is generated in a given language to avoid syntax collisions, e.g. this occurs with descriptor.proto in Haskell because "type" is a reserved word. Any of these might be extended with a string-valued option that would specify the mangled name, perhaps for just a specific language, perhaps in general. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
