The language guide in the documentation still doesn't describe Field
Options. I can see some references to them in some of the language
specific sections (Java, Python), but nothing telling us how to use
this feature either in fields or enums.
With this and other changes, it's really helpful for
Thank you Kenton & Shane - it must have been a slow brain day for me
yesterday :-)
I confused the underlying implementation with what PB provides. The
RPC system doesn't know or care how data is transferred.
On Nov 20, 5:56 pm, Shane Green <[EMAIL PROTECTED]> wrote:
> It sounds like the system i
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
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
> serv
I've been struggling to work out how to use PB's RPC mechanism within
my application. I don't have a problem with the simple usage of it or
the transport side. It's more how I would scale it up within a larger
modular application.
My application can run on multiple machines that need to talk to e
Has anyone devised a makefile rule for the .protoc->.cc->.o sequence?
Looking at the examples with PB, it currently uses a mechanism like
this:
protoc_middleman: addressbook.proto
protoc --cpp_out=. --java_out=. --python_out=.
addressbook.proto
@touch protoc_middleman
add_person
On Nov 13, 5:04 am, "Petar Petrov" <[EMAIL PROTECTED]> wrote:
> A few things. The current Python API has to remain pure-Python because some
> clients aren't able to use C/C++ extensions (like AppEngine).
> Boost is generally not accepted in Google, so a Boost::Pythonit interface
> will have to dis
On Oct 31, 5:19 am, "Petar Petrov" <[EMAIL PROTECTED]> wrote:
> Yes, there are plans to improve performance. I have spent a little time on
> this without significant improvements.
> I think performance can hardly get a drastic improvement without a C++
> extension module (which we are planning to
On Nov 8, 2:06 pm, Kenton Varda <[EMAIL PROTECTED]> wrote:
> 1. XML vs. Yet-Another-Proprietary-File-Format
> > The arguments against using XML at the wire-level are well documented,
> > but why, oh why, couldn't you have made the message definition format
> > (.proto) XML-based?
>
> Because XML i
On Nov 7, 11:06 am, Kenton Varda <[EMAIL PROTECTED]> wrote:
> I think either approach can work, and the trade-offs depend on your
> application. If your protocol messages are very complex, for instance, then
> maintaining parallel C++ classes can be a huge pain. On the other hand,
> protocol mes
e memory and processing overhead is of using
them.
I hope this makes my question clearer.
Thanks,
Jeff
> On Wed, Nov 5, 2008 at 12:06 AM, codeazure <[EMAIL PROTECTED]> wrote:
>
> > Does anyone have any thoughts on the use of PB message definitions for
> > interface only
Has anyone done any work on a plug-in for a UML charting program that
would allow it to generate .proto files as an output?
Rational Rose, for example, has a flexible code generation engine. It
should be possible to create a plug-in that would make .proto
development much easier.
Obviously, PB o
Does anyone have any thoughts on the use of PB message definitions for
interface only or throughout the implementation code as well?
I am planning a very modular application, where each module uses PB as
it's interface to external applications and inter-machine
communications within itself.
Shou
Thank you - this is a brilliant debugging tool & greatly helps
developers. Wireshark is such a flexible application that it suits
this sort of thing really well.
Thanks,
Jeff
On Sep 5, 9:26 am, Dilip Joseph <[EMAIL PROTECTED]>
wrote:
> View messages generated using Protocol Buffers in
> Wiresh
14 matches
Mail list logo
