Interesting ideas. Before we get too creative, though, let me say a word of caution: if an option affects the generated code in all languages (e.g. by changing the wire format), then it can't really be a "custom" option, since it will have to be compiled into protoc anyway. I'm very wary about adding such features, because while they're often very useful in certain cases, together they make the system more bloated, possibly harming more than helping overall (since all users get the additional bloat but only some actually use the feature). With that said, here's some more ideas:
* Cache keys: If you have a service which takes a protocol buffer request and returns a protocol buffer response with no side-effects, you could implement a caching layer over it. Cache keys could be generated by simply serializing the message and hashing it. However, your request messages might contain some fields which should be ignored when computing a cache key, e.g. options which only affect post-cache operations. You could use a custom option to mark which fields should be stripped before computing cache keys. * Auto interface generation: Someone mentioned before that they'd like to auto-generate a user interface for inputting or printing a protocol message in a friendly way. For this, it would be useful to have a custom string option called "description" which is a human-readable description of the field. On Thu, Sep 25, 2008 at 10:24 AM, Chris <[EMAIL PROTECTED]> wrote: > > 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 protobuf@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
