Implementing highly efficient binary protocol clients ands server using Google Protocol Buffers and Netty

2009-01-07 Thread Trustin Lee
Hi folks, As I posted a topic here before, I have done some integration for protobuf and Netty to enable the rapid implementation of highly efficient binary protocol clients and servers. With both technologies combined, you can build a socket client / server with protobuf very quickly. I'd

Re: Additional testing file

2009-01-07 Thread Jon Skeet
On Jan 6, 3:11 pm, Chris turingt...@gmail.com wrote: I found the attached protobuffer file quite useful in torture testing the ability to handle circular dependencies. Great, thanks - I'll try it against my C# port as soon as I can. Jon --~--~-~--~~~---~--~~

Re: Generating .proto files from C++ classes

2009-01-07 Thread Kenton Varda
How would that work, exactly? On Wed, Jan 7, 2009 at 11:50 AM, mikesparr...@gmail.com mikesparr...@gmail.com wrote: Is there an existing convert that can take a header file and produce a .proto file? --~--~-~--~~~---~--~~ You received this message because

Re: Generating .proto files from C++ classes

2009-01-07 Thread Alek Storm
On Jan 7, 4:21 pm, Kenton Varda ken...@google.com wrote: SWIG translates C/C++ APIs into other programming languages.  Protocol Buffers is not a programming language, so I don't see the analogy.  What would be the protocol buffer equivalent of a C function or a C++ class? Technically, SWIG

Re: Generating .proto files from C++ classes

2009-01-07 Thread Kenton Varda
Protocol buffers are useful even if all users are using the same language. In fact, we used them in C++ for some time before anyone bothered writing Java and Python implementations. On Wed, Jan 7, 2009 at 3:43 PM, Alek Storm alek.st...@gmail.com wrote: Mike, what exactly are you trying to

Re: Generating .proto files from C++ classes

2009-01-07 Thread Kenton Varda
On Wed, Jan 7, 2009 at 5:39 PM, Alek Storm alek.st...@gmail.com wrote: Right, I guess I didn't explain why they don't work in this case. Generating .proto files from C++ headers is obviously the reverse of the normal sequence. In the PB method of versioning, the original .proto is written

Re: Return value from CallMethod, default callback

2009-01-07 Thread Kenton Varda
I believe there was a proposal internally that if the caller passes None for the callback, the RPC implementation should block until completion and then return the result. Does that seem like what you want? On Wed, Jan 7, 2009 at 6:23 PM, Alan Kligman alan.klig...@gmail.com wrote: I poked

Re: Return value from CallMethod, default callback

2009-01-07 Thread Kenton Varda
Sounds fine to me, but it's up to Petar (cc'd). On Wed, Jan 7, 2009 at 7:04 PM, Alan Kligman alan.klig...@gmail.com wrote: Ya, that's exactly what I'm experimenting with now and precisely what I'm looking for. Would be perfect if the callback had a default value of None too. a On Jan 7,

Re: Generating .proto files from C++ classes

2009-01-07 Thread Alek Storm
On Jan 7, 8:18 pm, Kenton Varda ken...@google.com wrote: IMO, there's not much reason to use the protobuf wire format unless you explicitly intend for some users to read/write the format using actual protocol buffers. Not entirely sure what you mean. This will probably get a lot clearer once

Re: Return value from CallMethod, default callback

2009-01-07 Thread Pavel Shramov
On Wed, Jan 07, 2009 at 06:23:31PM -0800, Alan Kligman wrote: I poked around a bit and the code above isn't correct (for a couple of reasons). But the question remains: should stubs be generated that return the response down the callstack instead of passing it through a callback function?