Just define a message type which has no fields and use that. This way, if
you later decide that you actually want the client to be able to send some
information with the request, you can add it without breaking compatibility.
On Fri, May 22, 2009 at 12:48 PM, Jorge Fernandes wrote:
>
> Hello,
>
could go wrong or is it just information
> equivalent to the false return value of the function?
>
> Many thanks again.
>
> Dan
>
> On May 22, 5:44 pm, Kenton Varda wrote:
> > You can capture log output using SetLogHandler():
> http://code.google.com/apis/protocolbuff
You need to link against libprotobuf by adding -lprotobuf to your linker
command-line.
On Mon, May 25, 2009 at 7:46 AM, wrote:
>
> Hi,
>
> After successfully compiling my lib using a generated protocol buffer
> class, i am receiving this awful error when i try to load it:
> Unable to load dynami
On cygwin you should really use the provided configure script and
makefiles. Once you've installed the library you can use your IDE for your
own project that uses protocol buffers.
If you really want to compile with an IDE, then you will at least have to
run the configure script to produce config
Yep, that can be used in the place of None.
On Mon, May 25, 2009 at 6:47 AM, multijon wrote:
>
> Scratch that.
>
> I realized that using the has_field method I can check whether the
> field was initialized, which is equivalent to None.
>
> Jon
>
> On May 25, 4:46 pm, multijon wrote:
> > Hi,
> >
ay 26, 2009 at 1:08 AM, wrote:
>
> Thanks a lot!
>
> It worked well after i figured how to add it to the configure script
> of my PHP extension project:
> ./configure ... EXTRA_LDFLAGS='-lprotobuf'
>
> On 25 Mai, 21:50, Kenton Varda wrote:
> > You need to lin
I'll look into this when I get a chance. I have trouble understanding how
easy_install works, since I've never used it as a client. From the error
message it seems like it is trying to download the protobuf-2.1.0 full
package but expects it to contain only the Python sub-tree. I have no idea
how
Thanks for the patch, Monty.
Unfortunately it looks like it has been mangled somewhere in flight. Can
you send it as an attachment instead?
On Thu, May 21, 2009 at 11:01 AM, Monty Taylor wrote:
> Kenton Varda wrote:
> > On Wed, May 20, 2009 at 12:58 PM, Monty Taylor >
Submitted as rev 151.
On Wed, May 27, 2009 at 5:44 PM, Monty Taylor wrote:
> PS. Did you see the patch on issue 105 for ptrdiff and offsets_ ?
>
Yeargh, I wish I could tell the code site to e-mail me whenever someone
submits an issue, because I always forget to go look.
>
> === modified file
Sorry, there is not. I don't think this would be possible to do in a
type-safe way, since the same message type may be used by any number of
outer types.
On Thu, May 28, 2009 at 3:02 AM, naderp wrote:
>
> Hi,
>
> In the context of the C++ API and given a specific message instance,
> is there a
You can only have mutually-recursive messages if they are defined in the
same file.
I don't think your approach would work quite as you expect anyway. Message
fields are not pointers, so you can't have a recursive object at runtime.
That is, if you do:
message A {
optional B b = 1;
}
m
On Thu, May 28, 2009 at 12:17 PM, Marc Gravell wrote:
>
> A couple of questions on the new packed encoding;
>
> 1: do the core implementations complain if the body length is given as
> zero? i.e. no items? I don't expect they would *write* this, but would
> they be happy to *read* it? In particula
std::cout << "information from cc2 instance " << cc2->super
> ().abstractclassinformation() << endl;
>
>//test ClearExtension OK
>//ac->ClearExtension(ConcreteClass::derived_ConcreteClass);
>
>//test HasExtension OK
>
t char*) match
> >
> ./google/protobuf/stubs/common.h:586: note:
> google::protobuf::internal::LogMess
> age& google::protobuf::internal::LogMessage::operator<<(char)
> ./google/protobuf/stubs/common.h:587: note:
> google::protobuf::internal::LogMess
> age& g
The official implementations do NOT accept multiple encodings, but it would
theoretically be possible for them to do so. This wasn't implemented mainly
because code size bloat is a big problem and accepting multiple encodings
would increase code size -- even users who don't even use [packed=true]
Yep, you've found one of many ways that you can make protoc generate code
that does not compile. Unfortunately it would be extremely difficult and
tedious for us to fix every possible instance of this -- most of the
problems are things no one has even thought of yet -- so we try to focus
only on t
In theory I completely agree with you. :)
On Mon, Jun 1, 2009 at 9:55 AM, Joshua Haberman wrote:
>
> On Jun 1, 9:37 am, Kenton Varda wrote:
> > The official implementations do NOT accept multiple encodings, but it
> would
> > theoretically be possible for them t
I don't know much about protobuf-c specifically, but my guess is that it's
saying that it saw a tag with fixed64/sfixed64/double type that did not have
8 bytes after it -- i.e. the input was cut off in the middle of the value.
Probably what is happening is your message is being cut short in transi
Sorry, I don't understand your question. Can you write out the hypothetical
.proto file that defines these types, and example code showing what you
imagine the solution looking like?
On Mon, Jun 1, 2009 at 3:44 PM, ajoy wrote:
>
> Hi,
>
> If I have a chain of enclosed messages, e.g. A->B->C->D-
For the solution I want, I can keep a stack of field names, and keep
> pushing into it for every recursive call till I see 'e'. At that point I
> can concatenate all field names in the stack and get A.B.C.D.e as the fully
> qualified name of 'e'.
> Is there an easi
Yeah, we've dropped the ball on this. Unfortunately the people in charge of
the Python protocol buffers implementation also have other, apparently very
demanding projects, and thus Python protobuf hasn't gotten the attention it
deserves. Sadly even Google doesn't have infinite engineering resourc
There is not a built-in way to do this. I recommend creating a registry
object -- similar to ExtensionRegistry -- in which you can register all the
types you need to handle. Then you can register the types in high-level
code and pass that down to the RPC system, which itself then won't need to
kn
Done. I both added "VB" to the list of acronyms and added a separate copy
of the link under "Visual Basic" to make sure it's visible.
On Wed, Jun 3, 2009 at 3:36 AM, Marc Gravell wrote:
>
> protobuf-net now with added Visual Basic ;-p
>
> Please could you update the OtherLanguages wiki page
My position is that packed strings, bytes, messages, or groups are probably
not worth the effort, since the savings would be much less with them than
they are with primitives. Also, it would be harder to distinguish between
the packed and regular encodings for length-delimited types, since you end
Look at TextFormat (part of the C++, Java, and Python official
implementatinos) for an example of how descriptors and reflection can be
used to encode/decode messages in an alternative format. The TextFormat
class works with any message type, even ones not yet invented -- this is
when descriptors
f you were able to maintain both the --python_out and the --pylib_out
> options then users who need pure Python PB support (say for the App
> Engine etc) can use one and performance critical applications can use
> the other.
>
> Would it also be a good time to look at what would need to b
OK, I'm confused. The "packed" encoding is already supported for repeated
integers, floats, etc. Can you clarify some more?
On Wed, Jun 3, 2009 at 12:18 PM, Marc Gravell wrote:
>
> I'm sorry - I didn't do a good job with the question...
>
> I meant with things like integer, float, etc...
>
> Wi
Thanks for the patch!
It looks like you were using the examples as a test. Running "make check"
in the top directory will run a much better suite of tests -- do they pass?
Assuming it does work, can you re-send that patch as an attachment (it looks
like it has been mangled), or even send it to me
Sorry, Protocol Buffers only supports trees, not DAGs. So, you need to
devise some other way to identify objects on top of that.
On Thu, Jun 4, 2009 at 7:26 AM, wrote:
> // Add Wheel
> Wheel *to_replace = car->mutable_wheel();
> *to_replace = existing_wheel;
In this code you're actually makin
On Thu, Jun 4, 2009 at 5:23 AM, Stas Oskin wrote:
> Thanks for the tip, any idea if the plain UNIX pipes are working with
> protobuf?
>
You can send a protocol buffer over a pipe, sure. It's just bytes.
>
>
> Regards.
>
> 2009/5/25 Christopher Smith
>
> http://code.google.com/p/protobuf/wiki
When you compile your app, are you making sure to use the same C runtime
library against which you compiled libprotobuf? It looks like it's
complaining about missing functions in the C runtime.
On Thu, Jun 4, 2009 at 8:58 AM, wrote:
>
> Hi,
> I am trying to use Google Protocol Buffers run time
Yes, you need to use the protobuf runtime library. Each language has an
independent runtime library. libprotobuf.so is only for C++. For Java,
there is a Maven-built jar file on which you need to depend. You don't need
to link against the C++ dynamic library for Java apps.
On Thu, Jun 4, 2009 a
e
>
>
>
> On Thu, Jun 4, 2009 at 4:50 PM, Kenton Varda wrote:
>
>> When you compile your app, are you making sure to use the same C runtime
>> library against which you compiled libprotobuf? It looks like it's
>> complaining about missing functions in the C
7; versions and then the linker errors went away while building my
> application. I didnt find any other places where the older references were
> being used.
>
> I think you need to update your source to handle this issue.
>
> Thanks,
> Wayne
>
>
> On Thu, Jun 4, 2009 a
ng newer run time libraries than VS2003 to build my application,
> whilst using VS2003 to build the libraries. Sorry about the confusion.
>
> -Wayne
>
>
>
> On Fri, Jun 5, 2009 at 5:03 PM, Kenton Varda wrote:
>
>> You said you were using VS2003. According to your
It looks like it's having trouble finding stuff from the C++ standard
runtime. Did you make sure to link against the same version of the runtime?
On Sat, Jun 6, 2009 at 6:58 AM, wrote:
>
> Hi all,
> I have followed the steps suggested in readme.txt in vsprojects folder
> of protobuf. I copied t
I haven't seen that before. Can you set a breakpoint in malloc_error_break
like the error suggests and get a stack trace?
On Sun, Jun 7, 2009 at 4:23 AM, kgs wrote:
>
> Hi,
>
> I encountered a strange problem using protocol buffers on Mac OSX
> (Leopard).
>
> My configuration is:
> - libprotoc
()
> #11 0x001e1f29 in google::protobuf::Message::MergeFromCodedStream ()
> #12 0x001e2061 in google::protobuf::Message::ParseFromCodedStream ()
> #13 0x001e20a8 in
> google::protobuf::Message::ParseFromBoundedZeroCopyStream ()
> #14 0x001e21c3 in google::protobuf::Message::ParseFromString
On Mon, Jun 8, 2009 at 12:57 PM, kgs wrote:
> Any ideas?
Nope. :(
Let me know if you figure it out.
>
>
> Kamil
>
> On 8 Cze, 21:43, Kenton Varda wrote:
> > Strange. It looks like it's inside the STL string implementation that
> > something is going wr
Actually, optimize_for = SPEED is now the default (as of 2.1.0). (If there
is still documentation somewhere saying otherwise, point me at it so I can
fix it.)
The other option is optimize_for = CODE_SIZE. Protocol buffer generated
code can be surprisingly large -- we've seen binaries at google th
I still think that this doesn't belong in the scope of protocol buffers, but
rather some higher-level utility library.
That said, what does your proposal offer over the
writeDelimited/parseDelimited methods added to the Java runtime in 2.1.0?
(Still need to add them to C++ and Python...)
On Tue,
On Tue, Jun 9, 2009 at 12:11 AM, Jon Skeet wrote:
>
> On Jun 9, 1:42 am, Kenton Varda wrote:
> > In the next version there will be a third option: LITE_RUNTIME. This
> > variant is like optimizing for speed but will generate code that only
> > depends on a lighter
Ah, I see. How about if we just extend parseDelimited() to return null at
EOF?
On Tue, Jun 9, 2009 at 12:36 PM, Jon Skeet wrote:
>
> On Jun 9, 8:28 pm, Kenton Varda wrote:
> > I still think that this doesn't belong in the scope of protocol buffers,
> but
> > rather
Hrm, good point. We may need to consider a "tryMergeDelimited" to avoid
breaking anyone already using this interface. Bleh.
On Tue, Jun 9, 2009 at 10:33 PM, Jon Skeet wrote:
>
> On Jun 10, 12:01 am, Kenton Varda wrote:
> > Ah, I see. How about if we just extend pars
Sorry, there isn't, and I doubt that we would add this since it would
require every object to carry around an extra pointer. If you find your
system allocator is too slow, try using tcmalloc:
http://code.google.com/p/google-perftools/
On Wed, Jun 10, 2009 at 10:54 AM, druzhiche wrote:
>
> Hi,
>
Yep, sorry for changing it out from under you, but the old design was
possibly the dumbest thing I did when developing proto2. :/
On Thu, Jun 11, 2009 at 7:49 PM, daveb wrote:
>
> well, my diagnosis on the test code situation was largely wrong. i
> still think there is a problem detecting prot
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming
On Sun, Jun 14, 2009 at 4:14 PM, Alex Black wrote:
>
> Is there a way to start sending a message before its fully composed?
>
> Say we have messages like this:
>
> message Entity
> {
>required int32 id = 1;
>requi
This is tricky as the Python API (like the C++ API) has a strong sense of
ownership. Outer messages "own" the message objects embedded inside them.
In the Python API, this is necessary because assigning a field in an
optional sub-message may also cause the sub-message itself to become present
in
The Java implementation does not contain any mutable singletons, so as long
as you are accessing different objects, there is no need to worry about
thread-safety. So, yes, multiple threads may call parseFrom() at the same
time as long as they are parsing from different streams.
On Mon, Jun 15, 20
Everything you say sounds right. If you want to know precisely what these
methods do, or how much overhead they incur, I encourage you to look at the
code in repeated_field.h -- it's not very complicated.
However, instead of trying to control all this in detail, it's usually
easiest to simply make
I checked the code, and AFAICT, the error you are getting should only happen
with "string" fields, not "bytes". I wrote a test to make sure and, sure
enough, assigning a non-ASCII str to a "bytes" field worked fine. Can you
write a small program demonstrating the problem for us to debug?
On Tue,
On Tue, Jun 16, 2009 at 10:13 AM, RobertFach
wrote:
> So if I understood you right, say my example message test contains 10
> chunks, if I clear that message and parse another message containing 9
> chunks, no allocation would be performed and 1 cleared chunk object
> would still be in the object
Can you please send me example code which crashes when given invalid input,
and/or provide a stack trace for the crash?
Henner touched on some reason why the data may not have been correctly
transmitted. However, no input should ever cause the protobuf parser to
crash.
On Tue, Jun 16, 2009 at 7:4
Mostly looks fine.
Note that a varint can be up to 5 bytes. You should probably just use
CodedOutputStream::Varint32Size() to compute the exact size so that you can
allocate a buffer that is exactly large enough.
Also note that if your message is large (say, 10k or more), allocating a
single lar
a c++ style stream wrapper around a
> socket.
>
> - Alex
>
> --
> *From:* Kenton Varda [mailto:ken...@google.com]
> *Sent:* Wednesday, June 17, 2009 4:42 PM
> *To:* Alex Black
> *Cc:* Christopher Smith; Protocol Buffers
>
> *Subject:* Re: &#
The memory footprint of the protobuf library is around a megabyte
(stripped). It sounds like you have enough space for that. You don't need
to worry about speed or runtime memory usage (other than code footprint) --
the implementation is already very heavily optimized on both counts, and
that opt
Note that the protocol buffer parser is not asynchronous. That means you
either need to feed it an entire message at once, or it will need to block
waiting for mode data to arrive on the input stream. So if you want to do
something asynchronous, you best bet is probably to do your own buffering
u
On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda wrote:
> Note that the protocol buffer parser is not asynchronous. That means you
> either need to feed it an entire message at once, or it will need to block
> waiting for mode data to arrive on
s/mode/more
> the input stream. So
rs, but they
are not vectors. See documentation for repeated_field.h.
>
>
> message Foo {
> optional sequence< int32 > sequence_of_int32 = 1;
>
> }
>
>
> On Wed, Jun 17, 2009 at 4:34 PM, Kenton Varda wrote:
>
>> Can you please send me example code wh
stream is not strictly request/response. There can be multiple request
> messages in a row, ditto for responses.
>
> Regards,
> Brodie
>
>
> On Jun 19, 12:47 pm, Kenton Varda wrote:
> > On Thu, Jun 18, 2009 at 8:47 PM, Kenton Varda wrote:
> > > Note that the protoc
t many
> bytes. Really not very complicated.
>
> On Fri, Jun 19, 2009 at 10:53 AM, Kenton Varda wrote:
> > No, protocol buffers are not self-describing. The receiver needs to know
> > what type it is receiving, or you need to send the type information over
> the
> > wir
Currently, no, that is not supported. I'm happy to accept a patch which
adds the ability to use "infinity" and "nan" as default values for doubles
and floats.
On Fri, Jun 19, 2009 at 6:53 AM, dragan mihajlovic <
mihajlovic.dra...@gmail.com> wrote:
>
> Hi.
>
> Is there a way to specify NaN as a d
Sorry, Protocol Buffers do not provide support for searching or indexing.
All protobuf does is parse and serialize data structures. Drizzle is
actually building database functionality *on top* of protocol buffers --
they implement their own searching and indexing, using protocol buffers to
implem
oned in this post.
>
> Vikram
>
>
> On Jun 4, 1:42 pm, Kenton Varda wrote:
> > Thanks for the patch!
> > It looks like you were using the examples as a test. Running "make
> check"
> > in the top directory will run a much better suite of tests -- do t
Did you call ShutdownProtobufLibrary() before checking for leaks?
As it says, the memory in question is still reachable, so whether or not it
is a "leak" is debatable. ShutdownProtobufLibrary() will go around and
delete all the objects the library has allocated. It's a huge waste of time
if you'
The advantage of writing the length is that a parser can skip the entire
sub-message easily without having to parse its contents. Otherwise, we
would probably use the "group" encoding for sub-messages, where a special
end tag marks the end of the message.
On Tue, Jun 23, 2009 at 9:06 AM, etorri
You can use UnknownFieldSet, but be warned that the interface for that class
is likely to change in a future version (because the current design is
somewhat inefficient). If you just want to print the contents, you should
be fine -- just parse into an UnknownFieldSet and then call its toString()
m
1;
> required string target = 2;
> }
>
> So in this case there would not be need for an end tag. When
> constructing the message it should be relatively easy to count the
> number of embedded elements instead of knowing how much space they
> occupy. This would enable streaming/
group the data
by field number. Instead it will just have an array of number/value pairs
in arbitrary order (with groups still represented as embedded
UnknownFieldSets).
>
>
> On Jun 24, 2:12 am, Kenton Varda wrote:
> > You can use UnknownFieldSet, but be warned that the int
It will be treated like an unknown field. In C++ or Java, the value goes
into the UnknownFieldSet, so if you then serialize the message, it will
still be there. In Python it will just be discarded.
On Wed, Jun 24, 2009 at 2:56 AM, Stuart Johnson wrote:
>
> If a new enum value had been added to
> distinguish between packed arrays and byte blobs given only the encoded
> > message.
> >
> > > I'm ok with the interface changing in a future version as long as it
> > > supports extracting all of the data that it does today.
> >
> > Yes, it
e
> problem.
>
>
>
> On Jun 22, 4:38 pm, vikram wrote:
> > I am trying out what changes he suggested uptil now I am able to
> > compile but gtests are failing. I will update discussion once I am
> > able to find out whats going with gtests.
> >
> > Vikram
&g
If the tests pass, it should be good to go. Please do submit patches.
On Wed, Jun 24, 2009 at 2:09 PM, vikram wrote:
>
> I was finally able to compile it correctly and evaluate its
> correctness using tests.
>
> Kenton,
>
> Is there anything else I need to evaluate before using compiler
> a
TextFormat is intentionally designed to refuse unknown fields because
otherwise simple spelling errors would be silently ignored. Since
TextFormat is used for communicating with fallible humans rather than other
computers, catching errors seems more important than forward-compatibility.
What I sug
Yes, "groups" are never going to fully go away. But we recommend against
using them in new code.
On Thu, Jun 25, 2009 at 9:13 AM, Piotr Findeisen
wrote:
>
> Hi!
>
> On Jun 24, 8:42 pm, Kenton Varda wrote:
> > The end-tag approach is more efficient than your idea --
libprotobuf generally does not rely on dynamic initialization, and instead
uses pthread_once to initialize globals. The stack trace in that bug report
points at an object which is allocated by a pthread_once, so I don't think
initialization ordering can be the culprit here.
On Wed, Jun 24, 2009 at
The problem is that GCC emits two or three copies of each constructor. In
order to keep generated code size down, we moved the constructor code into a
separate method which could then be shared by the multiple copies that GCC
emits.
http://gcc.gnu.org/bugs.html#nonbugs_cxx
There is nothing "harmf
BTW, this was also reported awhile ago as issue 86:
http://code.google.com/p/protobuf/issues/detail?id=86
On Thu, Jun 25, 2009 at 12:55 PM, Kenton Varda wrote:
> The problem is that GCC emits two or three copies of each constructor. In
> order to keep generated code size down, we mov
One problem with javascript and protobuf is that you need a lot of support
code to parse the messages. Unless you end up sending quite a lot of stuff
back and forth, making the user download a JS protobuf codec library may be
a net loss. It may be better to use JSON or XML because browsers alread
The stack trace you provided looks like it is from v2.0.3. The
initialization code changed drastically in 2.1.0 -- the method
DescriptorPool::InternalBuildGeneratedFile no longer exists, for example.
Can you provide a stack trace using 2.1.0?
On Fri, Jun 26, 2009 at 8:07 AM, rodrigob wrote:
>
>
On Thu, Jun 25, 2009 at 6:59 PM, vikram wrote:
>
> Hello guys,
>
> I am actually attempting to compile protocol buffer source on
> AIX 5.3 and xlC 3.55 .
> It seems that I am able to compile it correctly but when it tried to
> use created protoc compiler it fails.
> So following it the snap
libprotobuf.so.4)
> #15 0xd1755298 in
> google::protobuf::compiler::CommandLineInterface::Run () from /work/
> vpatil/protobuf-2.1.0/src/.libs/libprotoc.a(libprotoc.so.4)
> #16 0x10002734 in main ()
> #17 0x11c4 in __start ()
>
>
> This one is what I found out when I debugg
Interface::Run
> (this=0x2ff22740, argc=3, argv=0x2ff228e0) at google/protobuf/compiler/
> command_line_interface.cc:352
> #17 0x10002894 in main (argc=3, argv=0x2ff228e0) at google/protobuf/
> compiler/main.cc:59
> #18 0x11ec in __start ()
>
>
> Vikram
>
> On J
Simply adding a mutex lock in every accessor wouldn't really make them
thread-safe. Consider:
if (my_message.has_foo()) {
DoSomething(my_message.foo());
}
This is not thread-safe if my_message can be modified in a separate thread
*even if* each accessor locked a mutex, because "foo" could
Protocol Buffers does not include an RPC implementation, only abstract
interfaces for one. ServiceDescriptor is useful for implementing your own
RPC system on top of protocol buffers -- it allows you to define your
services directly in the .proto file even though protocol buffers itself
does not p
very similar.
> This problem is being a show stopper for us, any help will be greatly
> appreciated...
>
> Regards,
> rodrigob.
>
> On Jun 26, 9:25 pm, Kenton Varda wrote:
> > The stack trace you provided looks like it is from v2.0.3. The
> > initialization co
You need to include zero_copy_stream_impl.h for FileOutputStream. You also
have an extra & in front of coded_stream which shouldn't be there, since
coded_stream is already a pointer.
On Mon, Jun 29, 2009 at 1:56 AM, tong cao wrote:
>
> When I chenge some codes from the example,I have had the fo
On Sun, Jun 28, 2009 at 7:30 AM, Alex Black wrote:
>
> Hi, I'm trying to use these to serialize messages to my own stream.
>
> I have a couple of questions:
>
> 1. If I use message.SerializeToCodedStream() do I still need to write
> the size of the message to the stream on my own first?
Yes.
Stream::~CodedOutputStream()
> Line 526 C++
> GraphPerf.exe!ProtoBufStreamAdaptor::~ProtoBufStreamAdaptor() Line 10 +
> 0x59 bytes C++
>
> --
> *From:* Kenton Varda [mailto:ken...@google.com]
> *Sent:* Monday, June 29, 2009 7:08 PM
> *To:* Alex
No, that doesn't make sense.
I need to see the exact code, from the point where the CodedOutputStream is
constructed until it is destroyed.
On Mon, Jun 29, 2009 at 5:35 PM, Kenton Varda wrote:
> Odd. By any chance, does this only happen when writing a zero-length
> message?
>
&
t; which is used to create protocol service and service stub classes from
> ServiceDescriptor objects at runtime.
>
> On Jun 29, 3:56 pm, Kenton Varda wrote:
> > Protocol Buffers does not include an RPC implementation, only abstract
> > interfaces for one. ServiceDescriptor is use
Protocol Buffers provides a way to convert between flat byte arrays and
structured data. This is obviously useful for network communication, but
protocol buffers does not provide any explicit networking support. It's up
to you to take the byte array generated by protocol buffers and send it over
Well, it's *supposed* to work as you say. But honestly, this code has not
been tested with blocking streams, since that's not how we use it in Google.
It's possible that there is a bug. But the code appears to be correct
AFAICT.
When CodedInputStream needs more data, it calls Refresh(), which lo
No, it can't. It requires generics. Sorry.
On Tue, Jun 30, 2009 at 7:32 AM, misha wrote:
>
> I was wondering if google protocl buffers can work with java 1.4
>
> >
>
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
e at runtime using the Importer
> class. This ultimately leaves me with a ServiceDescriptor. I'd like
> to instantiate that Service from the ServiceDescriptor.
> The python code has a ServiceStubBuilder class. Where is there a
> ServiceStubBuilder in the C++ API?
>
>
>
o this ?
> What sort of service would I need to be running on a server to send
> data (and have the server receive and convert the flat byte array into
> a Java object).
>
> On Jun 30, 2:32 pm, Kenton Varda wrote:
> > Protocol Buffers provides a way to convert between flat byte arr
some trouble thinking of use cases for this. How do
you intend to use this class? Why not just call RpcChannel directly
instead?
>
>
>
> On Jun 30, 2:08 pm, Kenton Varda wrote:
> > Oh, you want something like DynamicMessage except for services?
> > DynamicServiceStub, p
than using it to send data over the
> network and use on the other end.
> In fact is this not what it was invented for (communication).
>
> On 30 jun, 16:07, Kenton Varda wrote:
> > There are tons of resources on the internet and in books explaining how
> to
> > do ne
> "/work/vpatil/protobuf-2.1.0/src/./google/protobuf/descriptor.pb.h",
> line 23.10: 1540-0836 (S)
>
> The #include file is not found.
> "/work/vpatil/protobuf-2.1.0/src/./google/protobuf/extension_set.h",
> line 47.10: 1540-0836 (S)
>
> The #inclu
en
it would happen.
On Wed, Jul 1, 2009 at 10:18 AM, J.V. wrote:
>
> thanks, which product(s) does Google use internally or find most
> beneficial?
>
> Kenton Varda wrote:
> > You could look at one of the open source RPC implementations listed here:
> >
> >
&g
501 - 600 of 1581 matches
Mail list logo
