() or
callback.fail() would probably be clearer and less error prone (eg.
calling setFailed() and forgetting to call callback.run()). I would
definitely accept a breaking API change like this, but I can
understand that others who are using the RPC interface may not agree
with me.
Evan
--
Evan
, and are of course data dependent.
More benchmarks should be done before making a performance related
code change.
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Protocol Buffers
in that
context.
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
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
a mapping from message names to Message prototypes, so
you can create a Message of an appropriate type.
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
volunteering to do the work though. :)
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
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
at CodedInputStream
C++:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.io.coded_stream.html
Java:
http://code.google.com/apis/protocolbuffers/docs/reference/java/index.html?com/google/protobuf/CodedInputStream.html
--
Evan Jones
http://evanjones.ca
/~beechung/ref/gcc-intro.html
Evan
--
Evan Jones
http://evanjones.ca/
--~--~-~--~~~---~--~~
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
for each message.
The reason to use something more complicated is because lots of
applications already have some sort of buffer, and you want to try and
avoid extra copies.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
On Dec 7, 2009, at 0:02 , lexer wrote:
Adam, Could you please show simple example how to use tag number for
dispatch purpose.
I believe he was referring to this sort of thing:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
Hope this helps,
Evan
--
Evan Jones
http
?
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
Protocol Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more
= protobuffer.name().data()
this gets a pointer to the raw C string inside the C++ string object
inside the protocol buffer object. No allocations or copies will be
performed. Setting the string, one copy is always performed, as Kenton
mentioned.
Evan
--
Evan Jones
http://evanjones.ca/
--
You
buffer messages in both directions. In
fact, if you want to write an RPC implementation, you'll have to do
exactly that: send request messages one way, and reply messages the
other.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google
need to compile without RTTI, simply #define
GOOGLE_PROTOBUF_NO_RTTI.
// On MSVC, this should be detected automatically.
So add -DGOOGLE_PROTOBUF_NO_RTTI and it should work?
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
, std::string assumes buf is a NULL
terminated C string. You should use the following to create the string
with a specific length:
string another_copy(buf, msgStr.size());
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
/techniques.html#union
If you have many possible types, you may wish to consider implementing
a more complicated protocol where you send a header with the message
type string before the message.
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because
want.
See the techniques section on Union Types:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post
, unless I'm thinking about this in the wrong way? I haven't
actually thought about this very hard.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
On Feb 14, 2010, at 17:23 , SyRenity wrote:
Actually, answering myself it seems to be as simple as:
sData.assign(buffer, size); //Where size is the full buffer size
Yes, that works. See the following for more help:
http://www.sgi.com/tech/stl/basic_string.html
Evan
--
Evan Jones
http
have, but I fear that's
not
going to be very representative as they're mostly simple, flat
messages
where the bulk of the data is inside an opaque bytes field.
If it is representative for *your* application that is probably the
most important part.
Evan
--
Evan Jones
http://evanjones.ca
of a
mergeDelimitedFrom(CodedInputStream) would be welcomed.
You can do this yourself. I think the following would work:
int length = inputStream.readRawVarint32();
int oldLimit = inputStream.pushLimit(length);
builder.mergeFrom(inputStream);
inputStream.popLimit(oldLimit);
Evan
--
Evan Jones
http
protocol buffer in the same way, but it seems *possible*?
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send
Kenton Varda wrote:
With Protocol Buffers, we already say that fields can appear in any
order, so any security mechanism built around matching the raw bytes of
a protobuf message against some blacklist is obviously flawed.
Ah, I was not aware of that. Good to know.
Evan
--
Evan Jones
http
to figure out where this is happening. My unhelpful guess is that
something is not initialized correctly. Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email
On Mar 22, 2010, at 14:00 , Olan wrote:
const DIDS::Station station_iter = stationlog.station(k);
You probably want stationlog.mutable_station(k);
See:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp-generated.html#fields
Hope this helps,
Evan
--
Evan Jones
http
/protorpc/protorpcchannel_test)
==17815==by 0x804A8EF: (within
/home/evanj/hstore/hstore-async/build/protorpc/protorpcchannel_test)
==17815==by 0x80C3C08: __libc_csu_init (in
/home/evanj/hstore/hstore-async/build/protorpc/protorpcchannel_test)
--
Evan Jones
http://evanjones.ca/
--
You
valgrind. I'm assuming that
won't cause any weird failures, but if there might be some problem
that I haven't considered, please let me know.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post
buffers and strings. I'll
try to spend some time revisiting this at some point soon.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com
Evan Jones wrote:
Problem 2: Using the NIO encoders/decoders can be faster than
String.getBytes, but only if it is used = 4 times. If used only
once, it is worse. The same is approximately true about decoding.
Lame results: http://evanjones.ca/software/java-string-encoding.html
I'm
On May 3, 2010, at 21:11 , Evan Jones wrote:
Yes, I actually changed ByteString, since ByteString.copyFromUtf8 is
how protocol buffers get UTF-8 encoded strings at this point.
Although now that I think about it, I think it might be possible to
enable this only for SPEED messages
it doesn't overallocate quite as
much (in exchange my code does many copies).
Conclusion: there is a legitimate reason for this code to be faster
than the JDK's code. But it still may not be worth including this
patch in the main line protocol buffer code.
Evan
--
Evan Jones
http
need to test it to
be sure.
This is sort of just a fun experiment for me at this point, so who
knows when I may get around to actually finishing this.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group
there we should be able to decode directly from the input buffer,
saving a copy and an allocation of a temporary byte[] array. Unclear
if this will actually be significantly faster, but it might be
slightly faster.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message
others
are interested.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
a ThreadLocal?
From memory, the ThreadLocal appears to be very cheap, and not make
much performance difference, but I should double check this as well.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group
this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
call .resetSizeCounter() occasionally, I think it should work just
fine. I'm certainly using a single Java CodedInputStream per long
lived connection without any trouble. Unclear if I've sent 2GB of
data over a single connection though.
Evan
--
Evan Jones
http://evanjones.ca/
--
You
?
No, this should work just fine. On the input size, you'll need to call
CodedInputStream.resetSizeCounter() after each message, otherwise
you'll run into the size limit.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers
in 32.337s;
15.353779MB/s
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
On Jun 17, 2010, at 17:05 , Evan Jones wrote:
I'm working around this by moving the CodedInputStream inside my
loop, which is fine, but seems sub-optimal. At the very least, since
I have lots of small messages, this means my ZeroCopyInputStream's
methods get called many times.
Based
be
opposed to putting some effort into including it in protobuf, or in a
protobuf-utils type project.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
as they are written out, rather than
needing to serialize the entire thing to a byte[] array, then compress
it. This could be better, but as always you'll have to measure it.
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed
message.writeTo(servletOutputStream)
If you are writing multiple messages, you'll probably want to
explicitly create a single CodedOutputStream to write all of them.
If you experiment with this and find something different, I would be
interested to know.
Evan
--
Evan Jones
http://evanjones.ca
. This is trickier than re-using a single
CodedOutputStream. If you are interested, I can send the details about
what I have used. Although to be honest: I haven't tested it carefully
to see if this is *actually* faster than doing the simple thing such as
.parseFrom() and friends.
Evan
--
Evan Jones
http
(success);
This works for me.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf
);
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com.
For more
/ CodedOutputStream is probably
helpful.
Also: did you look at the third party libraries? Many programming
languages have implementations you could try using:
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you
luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr...@googlegroups.com
/Descriptors.Descriptor.html#getFullName()
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf
but the 'EnhancedRpcController' then
becomes a pervasive cast as well as a RPC implementation lockin
This is probably the worst part of the built-in service API, in my
opinion. I end up with casts related to controllers in lots of places.
Its ugly, but I don't see any good way to fix it.
Evan
--
Evan
(effectively). The second has to do
some sort of table lookup. You want to use the first form if you care
about performance.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email
be generated. Note that the .proto you sent
doesn't have RETRACTED defined, so maybe that is your problem?
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
is what that method does under the covers (I think).
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send
you have memory
corruption somewhere? Try using valgrind if you might have memory
corruption. Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
/browse_thread/thread/a4bc2a3788d356f6
Read that thread for details, but the summary is: patches welcomed.
CodedInputStream is pretty lightweight though, so creating and
destroying one per message should be pretty efficient.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message
, or MessageLite::
ParseFromBoundedZeroCopyStream).
Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send
On Aug 4, 2010, at 9:50 , mark.t.macdon...@googlemail.com wrote:
Is there a way I can do this without creating a Pixel pointer?
Something like this (which doesn't compile):
Try fractal.mutable_pixel(0)-set_*
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received
and fill in the length
field. This would be an incompatible change to the serialization
format, however.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto
message. However, I
suspect that isn't really a big overhead. You can also use
YourProtocolMessage.getDefaultInstance() to avoid creating a message.
Hope this helps,
Evan Jones
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
that improves Java
message *encoding* performance, by optimizing string encoding. It is
available at the following URL. Unfortunately, there is no similar
approach to improving the decoding performance.
http://codereview.appspot.com/949044/
Evan
--
Evan Jones
http://evanjones.ca/
--
You
#union
Two RPCs:
service Service {
rpc sendObject1(Object1) returns (Result1);
rpc sendObject2(Object2) returns (Result2);
}
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post
)
http://code.google.com/apis/protocolbuffers/docs/reference/java/com/google/protobuf/MessageLite.Builder.html#mergeDelimitedFrom(java.io.InputStream)
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group
service. Were I to start it today,
I would use the code generator, since there are a few small things in
the automatically generated RPC interface that I would like to change.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
is in the google::protobuf::internal namespace, rather than in
google::protobuf?
Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com
I never call the CodedInputStream routines unless I know
there is sufficient data. This may not be ideal for your application,
so your milage may vary.
Good luck,
Evan Jones
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups
it is convenient.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
rather than a struct or container type. There are some
languages which do not support more complex key types in their
native map types. In addition the JSON protocol only supports key
types that are base types.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you
:
codedOutput.WriteVarint32(msg.ByteSize());
msg.SerializeToCodedStream(codedOutput);
codedOutput.flush();
...
Hope this helps,
Evan
(as an aside: the C++ API really should have an equivalent to
writeDelimitedTo and parseDelimited on the Java side).
--
Evan Jones
http://evanjones.ca/
--
You received
) are coming out the other end and
getting passed into parseDelimited. It might be helpful if you sent a
snippet of code where you are sending and receiving the messages, but
I can't think of anything off the top of my head.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message
. The FileDescriptorTables are static
objects of sorts, I think. Are you calling ShutdownProtobufLibrary()
somewhere? Maybe more than once? Memory leaks *will* be reported by
valgrind if you don't call ShutdownProtobufLibrary(), but I don't know
what could cause a double free.
Evan
--
Evan Jones
if
that is getting called multiple times?
This FileDescriptorTable object is used internally by the protobuf
library and I don't really understand it. I'm hoping someone who might
understand this code might be able to suggest where this double free
could be coming from.
Evan
--
Evan
using the protobuf API: it handles any required
byte swapping for you.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from
for many conversations about this. Hope this helps,
Evan
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group
as well.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
http://www.javapractices.com/topic/TopicAction.do?Id=29)
That said, I think you *might* be able to hack something like this
using the Builder object. I would be interested to know if you try
this, and if it has any performance benefits.
Evan
--
Evan Jones
http://evanjones.ca/
--
You
On Oct 25, 2010, at 21:45 , Paul wrote:
optional string meas_rec_str = 2;
Change this to:
optional bytes meas_rec_str = 2;
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group
are serialized differently.
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email
only need to choose between a limited set of
types, you may want a union type or extensions instead:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
http://code.google.com/apis/protocolbuffers/docs/proto.html#extensions
Evan
--
Evan Jones
http://evanjones.ca/
--
You
://people.csail.mit.edu/evanj/hg/index.cgi/javatxn/file/tip/src/ca/evanjones/protorpc/ServiceRegistry.java
http://people.csail.mit.edu/evanj/hg/index.cgi/javatxn/file/tip/src/ca/evanjones/protorpc/ProtoMethodInvoker.java
Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because
. This is typically
easier since CopyingInputStreamAdaptor then implements the appropriate
buffering logic.
See:
http://code.google.com/apis/protocolbuffers/docs/reference/cpp/google.protobuf.io.zero_copy_stream_impl_lite.html#CopyingInputStreamAdaptor
Good luck,
Evan
--
Evan Jones
http
these objects. See:
http://code.google.com/apis/protocolbuffers/docs/javatutorial.html
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com
a length. See:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming
Or search the group archives for threads such as:
http://groups.google.com/group/protobuf/browse_thread/thread/3af587ab16132a3f
Good luck,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received
are using UDP, it will end up not working as soon as you
have a message which is bigger than either your buffer, or the maximum
UDP packet size, whichever comes first.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
already have both byte[] and
String fields for each string due to an encoding improvement I
contributed, so this should be nearly a pure win.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post
, although I don't think I ever considered this particular
version. However, I think this can be made thread-safe, even without
volatile (although I only understand the JMM enough to be dangerous).
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed
();
}
You can get defaultInstance from
ConcreteMessageType.getDefaultInstance();
You may want to create a tiny InputStream wrapper around ByteBuffer to
avoid an extra copy, or if you know it is a heap byte buffer, use the
array mergeFrom().
Hope that helps,
Evan
--
Evan Jones
http
Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email to
protobuf+unsubscr
he was interested in the same problem.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group, send email to proto...@googlegroups.com.
To unsubscribe from this group, send email
to worry about the ByteBuffer being accidentally
changed, etc). The latest version of Protocol Buffers in Subversion
has ByteString.copyFrom(ByteBuffer) which will do what you want
efficiently.
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed
) method of this class, so it is
actually pretty straightforward. There might be a better way but it
works for me. Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
Buffers group.
To post to this group
are really sending / writing a large number of
messages, you want to read something like:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming
Good luck,
Evan Jones
--
Evan Jones
http://evanjones.ca/
--
You received this message because you are subscribed to the Google
with the
framework you are using, but this should be feasible. Hope this helps,
Evan
--
Evan Jones
http://evanjones.ca/
--
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
/protorpc/ProtoConnection.java#l40
Evan
--
Evan Jones
http://evanjones.ca/
--
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
protobuf
work, but it works.
Evan
--
Evan Jones
http://evanjones.ca/
--
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
protobuf+unsubscr
of a pain. Good luck,
Evan Jones
--
http://evanjones.ca/
--
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
protobuf+unsubscr
message in the stream?. See:
http://code.google.com/apis/protocolbuffers/docs/techniques.html#union
the archives of this group also contain many discussions on this
subject.
Evan Jones
--
http://evanjones.ca/
--
You received this message because you are subscribed to the Google Groups Protocol
On Jan 25, 2011, at 15:27 , Hitesh Jethwani wrote:
As may be evident from above I am naive at Java and Protobuf. Any
help on this is appreciated.
The Java protocol buffer API encodes strings as UTF-8. Since C++ has
no unicode support, what you get on the other end is the raw UTF-8
On Jan 26, 2011, at 3:43 , Hitesh Jethwani wrote:
Can we encode the protobuf data in ISO-8859-1 from the server end
itself?
Yes. In this case, you need to use the protocol buffer bytes type
instead of the protocol buffer string type, since you want to
exchange ISO-8859-1 bytes from
I read this proposal somewhat carefully, and thought about it for a
couple days. I think something like this might solve the problem that
many people have with streams of messages. However, I was wondering a
couple things about the design:
* It seems to me that this will solve the problem
On Feb 8, 2011, at 13:34 , Kenton Varda wrote:
I handle user messages by passing them as bytes, embedded in my
own outer message.
This is what I do as well, as does protobuf-socket-rpc:
http://code.google.com/p/protobuf-socket-rpc/source/browse/trunk/proto/rpc.proto
I guess I was thinking
On Feb 21, 2011, at 3:06 , Amit Pandey wrote:
Did anyone get the chance to look into it.
If you want to use the RPC system, you need to provide your own
implementation, or maybe use an existing one, such as:
http://code.google.com/p/protobuf/wiki/ThirdPartyAddOns#RPC_Implementations
If
1 - 100 of 131 matches
Mail list logo
