Extensions about protobuf HOT 8 OPEN

I'm happy with this feature and PR for it :)

from protobuf.

As I said in #15 (comment). I want to give some ideas:

First of all, I want to give a summary about extensions and options in Protobuf:

1. Only protobuf2 supports extensions, protobuf3 only supports using extension for defining options.
2. Protobuf supports options in different levels(file, message, field, ...).
3. Developers can use extensions to define custom options(extend google.protobuf.*Options).

For your PR, I think there're some problems:

1. We need to split the implementations of extension and options because they're different features(in different PRs).
2. The way you implement extensions is a little complex(indeed, as you said, it's difficult 😄). So, is there a better way to do that?
3. Maybe we should let other projects handle custom options instead of in this lib.

For the 3rd problem(custom options), I looked into official Go implementation of protobuf and gRPC, I found it doesn't generate custom options for you. You have to use grpc-gateway plugin to generate code by using the custom options. The idea behind it, I think, is the protobuf lib should care about official defined options. For the custom options, it's the business of other plugins. In this way, the generated can be simpler(we only have what we need to use, like rpc definitions or http definitions).

Considering it's they're really advanced features, we can discuss more before implementing them.🙂

from protobuf.

As per 1: sorry that a lot has been pushed into this PR-- I've been using it for several projects in production.

As per 2, happy to discuss alternative implementations. Holistically, the issue was that we needed to parse everything once to define extensions and messages, and then parse everything in a second pass to allow extensions. This works well (minus the redefining of modules) and doesn't present real issues since the process is only called on protocol generation, not once the modules are loaded by a project.

For 3, my core question, and the one that led to this pull request is how to handle this protobuf:

extend google.protobuf.MethodOptions {
  // See `HttpRule`.
  HttpRule http = 72295728;
}

message Http {
  // A list of HTTP configuration rules that apply to individual API methods.
  //
  // **NOTE:** All service configuration rules follow "last one wins" order.
  repeated HttpRule rules = 1;
  // ...
}

For me, it's a sine qua non that a library I use has the ability to process and read from these protobufs. These are standard libraries and promoted by Google itself. Are you suggesting that we don't handle options and/or extensions at all? Again, I am happy to discuss how this is best implemented, but I think it's important that we make this library fully-featured with the official protobuf specifications.

from protobuf.

+1 for this. Looking forward to being merged!

from protobuf.

@tony612 Any thoughts on how we should handle addressing/merging this? For my usage, it's been pretty helpful. I wouldn't mind this ending up as a permanent fork (by a different name?) or looking for a way to merge. What do you think is best?

from protobuf.

@tony612 was about to start a pr to implement this also. Having options/extensions available in generated code is very useful for lots of different projects that I work on. We've been able to use these in the golang proto package to help us write libs but once I got to elixir I've had to pause until I can get access to the options.

@hayesgm wrt the code snippet at the start of this issue, would you consider the RPC/field signature to out the options map inside a keyword, keyed to :option?

from protobuf.

@tony612 Do you have any updates on support for options in protobuf-elixir?

from protobuf.

Since extension is implemented in #83 I think we can move forward to think about this again.

from protobuf.