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.