dev@grizzly.java.net

Re: Questions about Protocol Buffer Implementation

From: Oleksiy Stashok <oleksiy.stashok_at_oracle.com>
Date: Wed, 20 Apr 2011 17:35:54 +0200

Hi Chad,

the code looks fine! Later we can optimize it a bit, but it's very good
start!
Please see the comments inline...

> This is a first cute of the work for protocol buffers in grizzly
> https://github.com/cdollins/grizzly-google-protobufs
> grizzly-google-protobufs . Interestingly enough this can be cloned directly
> inside of extras and the extras pom only need reference the new module
> google-protobufs. Isn't git great!
yep :)

> Currently in the style of the StringFilter an int is used indicate protobuf
> message size in bytes. That is the assumption that all protocol buffers
> coming over the connection will be preceded by 4 bytes indicating the
> remaining bytes to read that represent the message itself.
Is it possible to determine the end of protobuf message w/o having a
length-prefix?

> Implementation Questions:
>
> 1. Do we want a variable length header i.e. varint encoded length header as
> is done in latest netty? This is similar to the
> http://code.google.com/apis/protocolbuffers/docs/encoding.html#varints
> protobuf it self's encoding
Even though I'm not a big fan of varint type (not sure I understand its
benefit), but IMO it could be a good idea to support it to be interopable.
What do you think?

> 2. Do we want to separate out the message length from protocol buffer
> message codec? This might relieve the burden of external applications to
> interpret the assumed byte size header and allow greater flexibility for
> header implementation. i.e. see the above possible encoding for a message
> size.
Agree.

> 3. What if multiple types protobuf messages come down the pipe? As far as I
> can tell netty does not address this issue. One possible solution is store a
> message code in a separate header preceding the message. What I would like
> to see which would solve a lot of problems is a kin to
> com.sun.jersey.config.property.packages initParam that detects classes to
> use as resources for a web application. That is automatically build up
> message type based on a set of classes. Just sayin.
Are we able to detect the protobuf message type?
 From the ProtobufDecoder code:

protobufMessage = message.newBuilderForType().mergeFrom(body).build();

not sure I see what we can change in order to support different protobuf
message types.
Any ideas?

Thanks a lot!

WBR,
Alexey.





> --
> View this message in context: http://grizzly.1045725.n5.nabble.com/Questions-about-Protocol-Buffer-Implementation-tp4305806p4314834.html
> Sent from the Grizzly - Development mailing list archive at Nabble.com.