If JSON is an option, how should protoc detect that a plugin wants to use
JSON? We could make it part of the filename, e.g.:
protoc-foo-json (implements --foo_out)
This seems ugly. But, other options I can think of (a config file, some
sort of handshake) would be a lot more complicated.
Hmm, perhaps protoc could start out assuming the generator wants binary
protos, but if it exits with a special error code, this indicates that it
would really prefer JSON instead. protoc then executes it again with the
--json command-line flag. This still seems convoluted, but less error-prone
than making it part of the file name.
I guess another option is for the plugin to start out by writing a line of
text to stdout specifying which encoding to use. protoc then has to wait
until it has received this line before it can send the generator request,
but that's probably not a big deal. On the other hand, if the plugin
doesn't write the line, protoc hangs, which may be awkward for people trying
to write plugins.
Another idea: protoc could always use binary format, but a tool could be
provided that translates between binary protobufs and json. Then if you
want JSON format, what you do is wrap your plugin in a simple shell script
which pipes the input and output through the translator tool. Thus protoc
only needs to know binary format and your tool only needs to know JSON.
Assuming most people only need to use JSON to bootstrap their initial
implementation, the extra complication of injecting a middleman may not be a
problem.
I like the last idea because it is the most modular. Any other ideas?
On Wed, Oct 28, 2009 at 8:24 PM, Neil T. Dantam mechs...@gmail.com wrote:
Kenton Varda wrote:
Also, writing third-party code generators in languages other than C++ is
tricky.
Yes, I opted not to bother with .proto parsing for s-protobuf, using only
the protobuf-encoded FileDescriptorSet's that protoc can emit.
Instead, I propose a similar architecture, but where each plugin is a
complete *binary*. protoc would invoke the binary as a sub-process and
communicate with it over stdin and stdout. The communication protocol
would
be defined using protocol buffers!
Sounds like an excellent idea, and since you seem to want to reuse
FileDescriptorSet, I could make this work with s-protobuf with
minimal effort.
To avoid the obvious bootstrapping problem when writing a code
generator in the language that it generates, we could add an
option for protoc to communicate with the plugin in JSON format
instead of protobuf binary format.
Personally, I solved this problem with a (very easy) manual
translation of FileDescriptorSet to the internal data structures
used by my code generator. JSON may be a nice extra, but it doesn't
seem like a hard requirement.
In fact, perhaps we should always communicate in JSON since it
would avoid binary/text conversion issues.
Please do provide the protobuf binary encoding, at least as an
option.
Thoughts?
This would be quite spiffy.
--
Neil
--~--~-~--~~~---~--~~
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
protobuf+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/protobuf?hl=en
-~--~~~~--~~--~--~---
