On Mon, Mar 09, 2009 at 02:11:54PM -0700, Marc Gravell wrote:
> As part of ongoing work looking at RPC (over a range of transports),
> one thing that keeps cropping up is sending messages via a RESTful API
> over http[s] (so the method to invoke it part of the URI, with the
> message as the body);
Kenton,
Thanks for your answers. I believe you've answered both of them.
My application unfortunately has very stringent requirements for the
format and layout of the data that will be streamed into and out of
it. Essentially, we will be sending binary data packets over a TCP or
UDP socket. Th
On Mon, Mar 9, 2009 at 2:45 PM, anthrope wrote:
>
> Hello all,
>I have only just begun looking at Protocol Buffers, and am
> intrigued, to say the least. I have taken a quick look at the library,
> and thought I would post a couple of questions before delvign further.
>
> First, is there supp
Hello all,
I have only just begun looking at Protocol Buffers, and am
intrigued, to say the least. I have taken a quick look at the library,
and thought I would post a couple of questions before delvign further.
First, is there support for the C/C++ uint16_t type? My application
needs to send
We haven't defined a MIME type.
Does it make sense to define a MIME type for protocol buffers in general, as
opposed to MIME types for individual protocols? The latter makes more sense
to me, since there's not much you can do with a protocol buffer without
knowing its type.
On Mon, Mar 9, 2009 at
As part of ongoing work looking at RPC (over a range of transports),
one thing that keeps cropping up is sending messages via a RESTful API
over http[s] (so the method to invoke it part of the URI, with the
message as the body); pretty trivial to do, but I wonder: is there any
common MIME type tha
If you are OK with the possibility that future versions of protocol buffers
may break your code (probably in minor ways), then you can do whatever you
want. If you aren't OK with that, then you should not subclass protocol
buffer types. There are tons of ways that future changes to the
implementa
It wasn't added because the reflection interface is already huge, and there
are a lot of different things that people could potentially want from it.
That said, I'd be OK with adding these. Fortunately they don't need
separate versions for every field type.
On Mon, Mar 9, 2009 at 5:50 AM, Scott
On Mon, Mar 9, 2009 at 6:12 AM, Marc Vaillant wrote:
> Except that you still have the shared lib load/unload problem :)
>
Yeah, well, I agree with you. I wish people wouldn't write programs that
attempt to exit while background threads are still running, but a lot of
people at Google (where we
On Fri, Mar 06, 2009 at 06:52:05PM -0800, Kenton Varda wrote:
> On Fri, Mar 6, 2009 at 6:41 PM, Marc Vaillant wrote:
>
>
> Static is dangerous in multithreaded scenarios for obvious reasons.
> These issues just add more complications.
>
>
> Static constants are not dangerous. All of
Hi -
I noticed that the functionality for Swap() and RemoveLast() was not
available to reflection. I needed them and tried to add them in a
branch, and it seemed trivial enough (especially RemoveLast). Is
there anything that I missed? Is there a reason that this is more
complex than I can see
Hi all
I'd like to add some Qt specific addditions to some generated gpb
classes, but I note the warning on the first C++ page of the
documentation:
"You should not create your own Foo subclasses. If you subclass this
class and override a virtual method, the override may be ignored, as
many gene
12 matches
Mail list logo
