I'd be wary about getting into too custom of applications here. People should make their own configuration files for GUI generator and caches, in my opinion; they're too complex and special-purpose and so on. For example, GUIs require more layout information than "render as slider" or something-- usually the layout groups information aesthetically etc. For caches, you need TTL type metadata usually anyways, so the cache implementation can easily provide hooks to custom compute the cache-key (which may be case-insenstive or approximate -- it's more tricky in general than a list of keys).
What protobuf does is to map between a wire protocol and code in some language. The .proto file should contain predominantly stuff to do with that. * I would really like the repeated field idea (since I have an app that serializes vectors as repeated doubles, ugh). I appreciate that every LB will require an update to handle it (since it changes the wire protocol), which is rather unpleasant. * There are a few C options I can see adding... * "inline" -- specify that a submessage field is be included inline in the message, instead of a pointer to the message. * "package_c_prefix" -- use this string instead of converting the package name to the prefix by changing "." to "__"; for deeply nested package names, this convention is too verbose. On Sep 26, 11:31 am, "Kenton Varda" <[EMAIL PROTECTED]> wrote: > 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 [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 -~----------~----~----~----~------~----~------~--~---
