Get desktop application:
View/edit binary Protocol Buffers messages
Describes a message type.
Used in:
Used in:
Describes an enum type.
Used in:
,Used in:
The parser stores options it doesn't recognize here. See above.
Describes a value within an enum.
Used in:
Used in:
The parser stores options it doesn't recognize here. See above.
Describes a field within a message.
Used in:
,If type_name is set, this need not be set. If both this and type_name are set, this must be either TYPE_ENUM or TYPE_MESSAGE.
For message and enum types, this is the name of the type. If the name starts with a '.', it is fully-qualified. Otherwise, C++-like scoping rules are used to find the type (i.e. first the nested types within this message are searched, then within the parent, on up to the root namespace).
For extensions, this is the name of the type being extended. It is resolved in the same manner as type_name.
For numeric types, contains the original text representation of the value. For booleans, "true" or "false". For strings, contains the default text contents (not escaped in any way). For bytes, contains the C escaped value. All bytes >= 128 are escaped. TODO(kenton): Base-64 encode?
Used in:
0 is reserved for errors
TODO(sanjay): Should we add LABEL_MAP?
Used in:
0 is reserved for errors. Order is weird for historical reasons.
Not ZigZag encoded. Negative numbers
take 10 bytes. Use TYPE_SINT64 if negative values are likely.
Not ZigZag encoded. Negative numbers
take 10 bytes. Use TYPE_SINT32 if negative values are likely.
Tag-delimited aggregate.
Length-delimited aggregate.
New in version 2.
Uses ZigZag encoding.
Uses ZigZag encoding.
Used in:
The ctype option instructs the C++ code generator to use a different representation of the field than it normally would. See the specific options below. This option is not yet implemented in the open source release -- sorry, we'll try to include it in a future version!
The packed option can be enabled for repeated primitive fields to enable a more efficient representation on the wire. Rather than repeatedly writing the tag and type for each element, the entire array is encoded as a single length-delimited blob.
Is this field deprecated? Depending on the target platform, this can emit Deprecated annotations for accessors, or it will be completely ignored; in the very least, this is a formalization for deprecating fields.
EXPERIMENTAL. DO NOT USE. For "map" fields, the name of the field in the enclosed type that is the key for this map. For example, suppose we have: message Item { required string name = 1; required string value = 2; } message Config { repeated Item items = 1 [experimental_map_key="name"]; } In this situation, the map key for Item will be set to "name". TODO: Fully-implement this, then remove the "experimental_" prefix.
The parser stores options it doesn't recognize here. See above.
Used in:
Default mode.
Describes a complete .proto file.
Used in:
file name, relative to root of source tree
e.g. "foo", "foo.bar", etc.
Names of files imported by this file.
All top-level definitions in this file.
The protocol compiler can output a FileDescriptorSet containing the .proto files it parses.
Used in:
Sets the Java package where classes generated from this .proto will be placed. By default, the proto package is used, but this is often inappropriate because proto packages do not normally start with backwards domain names.
If set, all the classes from the .proto file are wrapped in a single outer class with the given name. This applies to both Proto1 (equivalent to the old "--one_java_file" option) and Proto2 (where a .proto always translates to a single class, but you may want to explicitly choose the class name).
If set true, then the Java code generator will generate a separate .java file for each top-level message, enum, and service defined in the .proto file. Thus, these types will *not* be nested inside the outer class named by java_outer_classname. However, the outer class will still be generated to contain the file's getDescriptor() method as well as any top-level extensions defined in the file.
Should generic services be generated in each language? "Generic" services are not specific to any particular RPC system. They are generated by the main code generators in each language (without additional plugins). Generic services were the only kind of service generation supported by early versions of proto2. Generic services are now considered deprecated in favor of using plugins that generate code specific to your particular RPC system. If you are using such a plugin, set these to false. In the future, we may change the default to false, so if you explicitly want generic services, you should explicitly set these to true.
The parser stores options it doesn't recognize here. See above.
Generated classes can be optimized for speed or code size.
Used in:
Generate complete code for parsing, serialization,
etc.
Use ReflectionOps to implement these methods.
Generate code using MessageLite and the lite runtime.
Used in:
Set true to use the old proto1 MessageSet wire format for extensions. This is provided for backwards-compatibility with the MessageSet wire format. You should not use this for any other reason: It's less efficient, has fewer features, and is more complicated. The message must be defined exactly as follows: message Foo { option message_set_wire_format = true; extensions 4 to max; } Note that the message cannot have any defined fields; MessageSets only have extensions. All extensions of your type must be singular messages; e.g. they cannot be int32s, enums, or repeated messages. Because this is an option, the above two restrictions are not enforced by the protocol compiler.
Disables the generation of the standard "descriptor()" accessor, which can conflict with a field of the same name. This is meant to make migration from proto1 easier; new code should avoid fields named "descriptor".
The parser stores options it doesn't recognize here. See above.
Describes a method of a service.
Used in:
Input and output type names. These are resolved in the same way as FieldDescriptorProto.type_name, but must refer to a message type.
Used in:
The parser stores options it doesn't recognize here. See above.
Describes a service.
Used in:
Used in:
The parser stores options it doesn't recognize here. See above.
A message representing a option the parser does not recognize. This only appears in options protos created by the compiler::Parser class. DescriptorPool resolves these when building Descriptor objects. Therefore, options protos in descriptor objects (e.g. returned by Descriptor::options(), or produced by Descriptor::CopyTo()) will never have UninterpretedOptions in them.
Used in:
, , , , , ,The value of the uninterpreted option, in whatever type the tokenizer identified it as during parsing. Exactly one of these should be set.
The name of the uninterpreted option. Each string represents a segment in a dot-separated name. is_extension is true iff a segment represents an extension (denoted with parentheses in options specs in .proto files). E.g.,{ ["foo", false], ["bar.baz", true], ["qux", false] } represents "foo.(bar.baz).qux".
Used in: