Re: Custom EnumValueOptions?
Good news: There was a patch for this submitted to the internal version of
the code which should make its way to SVN today or tomorrow, and will be in
the 2.0.3 release.
On Wed, Nov 19, 2008 at 1:29 AM, Jerry Cattell [EMAIL PROTECTED]wrote:
I'm trying to use a custom EnumValueOption:
package test;
import google/protobuf/descriptor.proto;
extend google.protobuf.EnumValueOptions {
optional string code = 1234;
}
enum ProductType {
ROCK = 0 [(code) = R];
PAPER = 1 [(code) = P];
SCISSORS = 2 [(code) = S];
}
However, this doesn't seem to parse:
test.proto:9:12: Expected ;.
test.proto:10:13: Expected ;.
test.proto:11:16: Expected ;.
Looking at unittest_custom_options.proto, it mentions a TODO for
this. Are custom EnumValueOptions currently supported? If not, any
idea when they will be?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
Re: RPC Design Structure
On Nov 20, 7:58 am, Kenton Varda [EMAIL PROTECTED] wrote: I'm not sure I understand. There's nothing stopping you from spreading your definitions out among multiple .proto files which import each other, and there's nothing stopping you from exporting multiple services from a single server. You'll need to design a protocol that allows it, but protocol buffers doesn't do anything to prevent it. Can you be more specific about the problem you're facing, maybe giving an example? I can have multiple services per server? That's what I wanted to know. I could not any place in the documentation where it talked about whether Service has a 1:1 or Many:1 relationship with RpcController. It seemed like it was 1:1 from all the examples I had seen, hence my confusion. Next time you're updating the docs in this area, it might be worth changing the example to show 2 Services so it's clear to others. I was also thinking of services running on ports on Linux systems. In this situation, it is a 1:1 relationship between services and ports. I know it's a different situation, but my thinking got stuck on the term service. If I can define as many services as I like and attach them all to the same RPC Controller, then that will answer my question give me the extensible modular design I want. I had thought there had to be an answer like this because I couldn't imagine Google's internal applications would want to be bound by such a serious limitation. Thanks! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: RPC Design Structure
RpcController objects are per-request, not per-server or per-service. For every RPC request you make, you should have another RpcController object (though you can reuse an object by calling Clear() as long as you aren't making two requests at once). RpcChannel objects are per-service. Is that what you were thinking of? A single RpcChannel represents a connection to a single Service. However, there's nothing stopping you from multiplexing multiple RpcChannels across a single TCP connection, or creating a protocol that allows you to choose between multiple services exported by a server when constructing an RpcChannel. On Wed, Nov 19, 2008 at 5:06 PM, codeazure [EMAIL PROTECTED] wrote: On Nov 20, 7:58 am, Kenton Varda [EMAIL PROTECTED] wrote: I'm not sure I understand. There's nothing stopping you from spreading your definitions out among multiple .proto files which import each other, and there's nothing stopping you from exporting multiple services from a single server. You'll need to design a protocol that allows it, but protocol buffers doesn't do anything to prevent it. Can you be more specific about the problem you're facing, maybe giving an example? I can have multiple services per server? That's what I wanted to know. I could not any place in the documentation where it talked about whether Service has a 1:1 or Many:1 relationship with RpcController. It seemed like it was 1:1 from all the examples I had seen, hence my confusion. Next time you're updating the docs in this area, it might be worth changing the example to show 2 Services so it's clear to others. I was also thinking of services running on ports on Linux systems. In this situation, it is a 1:1 relationship between services and ports. I know it's a different situation, but my thinking got stuck on the term service. If I can define as many services as I like and attach them all to the same RPC Controller, then that will answer my question give me the extensible modular design I want. I had thought there had to be an answer like this because I couldn't imagine Google's internal applications would want to be bound by such a serious limitation. Thanks! --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Re: RPC Design Structure
Thanks for the breakdown, that's very helpful. I had some trouble finding details about how the PB RPC terminology mapped to what I'm familiar with. It sounds like the system in question has a single public service with delegates calls to back-end services, distributed across machines available to it. It seems as though the public service provides an interface which is essentially a composition of the interfaces provided by the services available to it. The process of accepting requests for methods it provides on behalf of these back-end services, which it handles by delegating to the appropriate back-end service, is essentially multiplexing multiple services from a single network location. If this is at all accurate, then I believe that the API exported by the public service should be built, dynamically, based on the set of interfaces available to it. Taking this approach would allow each service to define its own interface. While all the functionality available on the network can be exposed as though it were all provided by a single entity, assuming there are no naming conflicts ;-) Or maybe I'm completely confused about the setup. Best regards, Shane On Wed, 2008-11-19 at 22:37 -0800, Kenton Varda wrote: The design of an RPC system is a large topic and there are lots of different ways you could do it. The RPC interfaces provided by Protocol Buffers are meant to provide the minimum support necessary to allow protoc to generate type-safe service stubs. How you want to implement them is up to you. This is described in the docs, but to summarize, the basic classes are: Service: An object that receives messages, possibly from remote clients. protoc generates an interface corresponding to each service in a .proto file. These interfaces are implemented by the server application. RpcChannel: Represents an abstract tunnel to a single service, allowing you to send messages just to that service. This is an abstract interface which should be implemented by the RPC library. RpcController: Manages state related to a single remote procedure call -- that is, a single message sent to the server, and its corresponding response. This is an abstract interface which should be implemented by the RPC library. Stub: A fake implementation of a service interface which just forwards messages to an RpcChannel. This makes the service appear to be a local object when it is not. protoc automatically generates a stub class for every service type. Note that you could easily have multiple RpcChannels that share a single TCP connection and lead to multiple service objects running on a single server. The interfaces are designed to put as few restrictions on implementations as possible. On Wed, Nov 19, 2008 at 9:52 PM, codeazure [EMAIL PROTECTED] wrote: OK, now you've confused me :-) I don't understand the exact relationship between all these classes, which is why I'm asking the question. If I want to build an application where I have a number of services that share a single TCP port, what organisation do I need to use? You mention multiplexing services - what does that mean for a client application using the connection? A UML:diagram (or similar) showing the relationship between controllers, channels services would really aid my understanding of how this system would operate. Perhaps these terms are in common usage in other RPC systems, but because I haven't used any, I'm uncertain about what these entities do. I've read the documentation several times, but the overview of how it works hasn't clicked. Thanks, Jeff On Nov 20, 12:54 pm, Kenton Varda [EMAIL PROTECTED] wrote: RpcController objects are per-request, not per-server or per-service. For every RPC request you make, you should have another RpcController object (though you can reuse an object by calling Clear() as long as you aren't making two requests at once). RpcChannel objects are per-service. Is that what you were thinking of? A single RpcChannel represents a connection to a single Service. However, there's nothing stopping you from multiplexing multiple RpcChannels across a single TCP connection, or creating a protocol that allows you to choose between multiple services exported by a server when constructing an RpcChannel. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Protocol Buffers group. To post to this group,
Re: Makefile rules
On Mon, Nov 17, 2008 at 17:02, codeazure [EMAIL PROTECTED] wrote: Has anyone devised a makefile rule for the .protoc-.cc-.o sequence? ... This appears to work well, but I was hoping it is possible to define a .proto.cc rule to automate it by some cleverness. My project uses Automake it is easy to define custom make rules for different extensions. I've been using the following, which works well in GNU make[1]. I'm using a non-recursive makefile[2], and have a separate directory tree under $GENDIR for all generated files (.o, .pb.cc, etc). I sort of use that to good effect in making sure the regular rule for cc files won't apply accidentally, because the pb.cc files are in a different location. == # Make a directory unless it already exists maybe-mkdir = $(if $(wildcard $1),,mkdir -p $1) # C++ build rule. $(GENDIR)/%.o: %.cc $(call maybe-mkdir, $(dir $@)) $(CC) $(CFLAGS) -c $ -o $@ # Protobuffer code generation rules (note the first rule has multiple targets). $(GENDIR)/%.pb.h $(GENDIR)/%.pb.cc: %.proto $(call maybe-mkdir, $(dir $@)) $(PROTOC) -I. --cpp_out=$(GENDIR) $ $(GENDIR)/%.pb.o: $(GENDIR)/%.pb.cc $(CC) $(PROTO_CFLAGS) -c $ -o $@ == [1] Rule #1, http://make.paulandlesley.org/rules.html [2] Recursive make considered harmful, http://miller.emu.id.au/pmiller/books/rmch/ --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
