ack it receives, where to pass the return
value, then that is more useful and safe.
On Jan 8, 3:48 pm, Pavel Shramov wrote:
> On Thu, Jan 08, 2009 at 10:00:35AM -0800, Alan Kligman wrote:
> > That's one way to do it. You can do one better( without threading,
> > that is ) like th
alue later and actually return it.
alan
On Jan 8, 2:46 am, Pavel Shramov wrote:
> On Wed, Jan 07, 2009 at 06:23:31PM -0800, Alan Kligman wrote:
>
> > I poked around a bit and the code above isn't correct (for a couple of
> > reasons). But the question remains: should stubs
gt; the callback, the RPC implementation should block until completion and then
> return the result. Does that seem like what you want?
>
> On Wed, Jan 7, 2009 at 6:23 PM, Alan Kligman wrote:
>
> > I poked around a bit and the code above isn't correct (for a couple of
&g
I poked around a bit and the code above isn't correct (for a couple of
reasons). But the question remains: should stubs be generated that
return the response down the callstack instead of passing it through a
callback function?
On Jan 7, 5:59 pm, Alan Kligman wrote:
> Does it make
Does it make sense to change
stub.rpc_channel.CallMethod(
method_descriptor, rpc_controller, request,
method_descriptor.output_type._concrete_class, callback)
to
return stub.rpc_channel.CallMethod(
method_descriptor, rpc_controller, request,
method_descri
ay to specify the python
> package explicitly in the .proto file, similar to the java_package option,
> rather than just inferring it from the location of the .proto file.
>
> On Tue, Oct 28, 2008 at 7:49 AM, Alan Kligman <[EMAIL PROTECTED]>wrote:
>
>
>
> > I need th
ative to the importing file.
>
> On Sat, Oct 25, 2008 at 7:11 PM, Alan Kligman <[EMAIL PROTECTED]>wrote:
>
>
>
> > I'm having a problem with protoc where python imports are not done
> > correctly. Here's the situation:
>
> > I have a dir
Authentication doesn't really belong here. You should either use an
authenticated transport (like HTTPS), or in the layer above (this is
what I'm currently doing).
On Oct 27, 8:54 pm, "Paul P. Komkoff Jr" <[EMAIL PROTECTED]> wrote:
> On 26 окт, 02:53, Alan Klig
I haven't had much to add recently. Protobuf-rpc is based heavily on
json-rpc, so there's really nothing new behind it. It works well for
my own use and is generic enough to probably work well for most other
people.
Is there a great deal of interest in devising a standard rpc protocol
definition?
I'm having a problem with protoc where python imports are not done
correctly. Here's the situation:
I have a directory structure like this:
proto/a.proto
proto/a/b.proto
proto/a/c.proto
a.proto provides some common definitions for both b.proto and c.proto.
I build the output like this:
protoc
10 matches
Mail list logo
