On Wed, Feb 24, 2010 at 9:59 AM, ph <pkirsa...@gmail.com> wrote:

> On the high level I have a wrapper for RpcChannel implements
> transport.


RpcChannel's only reason for existence is for creating stub objects, and
those stubs already know what type of messages to use.  Why are you writing
something else that "wraps" RpcChannel?  Maybe you should define an
interface called RawRpcChannel instead, which takes ByteStrings instead of
Messages?


> Inside transport I need to parse response. To do that I
> need and instance of service.
> To create an instance of service (stub) I need to provide and instance
> of channel to it. So, my service depends on channel and channel
> depends on service.
> I have multiple channels (pool) I'm using to send/receive each packet.
> If I want to hide my implementation guts, I don't want user to create
> service and then call another method to link that service with channel
> (I don't have access to service from channel).
> This is in nutshell my egg-chicken dilemma. So I want to get rid of
> one of dependencies, and the one I thought about was replacing Service
> implementation with Descriptor...
>
> On Feb 24, 12:40 pm, Kenton Varda <ken...@google.com> wrote:
> > The way this is intended to work is that you should have a pointer to the
> > Service object and call its getRequestPrototype() method.  I don't
> > understand why you would need to decode requests without having a Service
> > object for which they are destined.
> >
> >
> >
> > On Tue, Feb 23, 2010 at 8:56 PM, ph <pkirsa...@gmail.com> wrote:
> > > Thanks
> >
> > > It looks like there is no elegant way to solve my issue.
> > > In short, I have a transport implementation to use with PB RPC
> > > service.
> > > Service definitions are built-in and I need to convert byte array to
> > > Message inside my transport. I know what service transport handles and
> > > I have method name.
> > > ServiceDescriptor has descriptors of all types I possibly need, but
> > > unfortunately I looks like there is no way to construct message from
> > > byte array having MessageDescriptor (which I can get from
> > > ServiceDescriptor).
> >
> > > On Feb 23, 7:28 pm, Kenton Varda <ken...@google.com> wrote:
> > > > (But to answer your question:  Compiled-in types are almost always
> faster
> > > > than DynamicMessage.)
> >
> > > > On Tue, Feb 23, 2010 at 4:27 PM, Kenton Varda <ken...@google.com>
> wrote:
> > > > > I'm not sure how your approach works, but since it looks like
> you're
> > > using
> > > > > Java reflection, my guess is that it will only work with
> compiled-in
> > > > > services.  If your code is a library, this will prevent users of
> that
> > > > > library from using dynamic types, which is unfortunate.  If the
> users
> > > > > provide a default instance, then they can choose to provide either
> a
> > > > > compiled-in type or a dynamic type.
> >
> > > > > On Tue, Feb 23, 2010 at 1:55 PM, ph <pkirsa...@gmail.com> wrote:
> >
> > > > >> Thanks Kenton,
> >
> > > > >> I was using getRequestPrototype, but I need an actual instance of
> > > > >> Service to call that method that created additional extra
> dependency
> > > > >> in my code that why I started to look for alternatives. I know my
> > > > >> method name and currently I'm just parsing response (byte array)
> this
> > > > >> way (in Scala):
> > > > >> Class.forName ( String.format ( classNameFormat, methodName ) )
> > > > >>        .getDeclaredMethod ( "parseFrom", Array ( msg.getClass ) :
> _* )
> > > > >>        .invoke ( null, Array ( msg ) : _* ).asInstanceOf
> > > > >> [ com.google.protobuf.GeneratedMessage ]
> > > > >> This works fine. I will try to use a Default Message or
> > > > >> DynamicMessage, thanks for suggestion. From the top of your head,
> do
> > > > >> you think DynamicMessage will be faster or slower than my
> approach?
> >
> > > > >> On Feb 22, 6:10 pm, Kenton Varda <ken...@google.com> wrote:
> > > > >> > Right, Descriptor.toProto() returns a DescriptorProto, which is
> > > itself a
> > > > >> > protobuf type.  So, calling newBuilderForType() on that is going
> to
> > > > >> return a
> > > > >> > builder for DescriptorProto, not a builder for the type
> described.
> >
> > > > >> > What you want is com.google.protobuf.DynamicMessage.
> >
> > > > >> > Note that DynamicMessage is slower than the message classes
> produced
> > > by
> > > > >> > protoc.  So if the type in question is actually compiled in to
> your
> > > app,
> > > > >> you
> > > > >> > should use it instead.  Typically what you'd do is pass around
> the
> > > > >> type's
> > > > >> > default instance (MyMessageType.getDefaultInstance()) instead of
> > > passing
> > > > >> > around the descriptor.
> >
> > > > >> > Note that the Service interface also provides a method
> > > > >> > getRequestPrototype(MethodDescriptor) which returns the default
> > > instance
> > > > >> for
> > > > >> > the type, on which you can then call newBuilderForType().
> >
> > > > >> > On Sat, Feb 20, 2010 at 12:54 PM, ph <pkirsa...@gmail.com>
> wrote:
> > > > >> > > I'm trying to build service return message using
> > > > >> > > Descriptors.ServiceDescriptor.
> > > > >> > > This does not work:
> > > > >> > > serviceDescriptor.findMethodByName
> > > > >> > > ( methodName
> ).getOutputType.toProto.newBuilderForType.mergeFrom
> > > > >> > > ( msg ).build
> > > > >> > > "msg" is byte array
> > > > >> > > It builds DesscriptorProtos.DescriptorProto instead of
> Message.
> >
> > > > >> > > Is there a way to build message from byte array using method
> > > > >> > > descriptor?
> >
> > > > >> > > --
> > > > >> > > You received this message because you are subscribed to the
> Google
> > > > >> Groups
> > > > >> > > "Protocol Buffers" group.>> > > To post to this group, send
> email
> > > toproto...@googlegroups.com.
> > > > >> > > To unsubscribe from this group, send email to>> > >
> > > protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com>
> <protobuf%2bunsubscr...@googlegroups.c om>
> > > <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@googlegroups.com>
> <protobuf%252bunsubscr...@googlegro ups.com>
> >
> > > > >> <protobuf%2bunsubscr...@googlegroups.c om>
> > > > >> > > .
> > > > >> > > For more options, visit this group at
> > > > >> > >http://groups.google.com/group/protobuf?hl=en.
> >
> > > > >> --
> > > > >> You received this message because you are subscribed to the Google
> > > Groups
> > > > >> "Protocol Buffers" group.>> To post to this group, send email
> > > toproto...@googlegroups.com.
> > > > >> To unsubscribe from this group, send email to>>
> > > protobuf+unsubscr...@googlegroups.com<protobuf%2bunsubscr...@googlegroups.com>
> <protobuf%2bunsubscr...@googlegroups.c om>
> > > <protobuf%2bunsubscr...@googlegroups.com<protobuf%252bunsubscr...@googlegroups.com>
> <protobuf%252bunsubscr...@googlegro ups.com>
> >
> > > > >> .
> > > > >> For more options, visit this group at
> > > > >>http://groups.google.com/group/protobuf?hl=en.
> >
> > > --
> > > 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<protobuf%2bunsubscr...@googlegroups.com>
> <protobuf%2bunsubscr...@googlegroups.c om>
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/protobuf?hl=en.
>
> --
> 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<protobuf%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/protobuf?hl=en.
>
>

-- 
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 options, visit this group at 
http://groups.google.com/group/protobuf?hl=en.

Reply via email to