Thanks, I'll look at io.grpc when I get a chance.

On Wednesday, June 7, 2017 at 8:24:59 PM UTC-4, [email protected] wrote:
>
> Hi Jason,
>
>  
>
> Thanks for working on this! Apologies for the delay in getting back to 
> you. We took a closer look at the prototype and at the moment it looks like 
> most of the work has been around the jbuilder integration and stubbing out 
> of C core implementation to get most of the tests passing (do let me know 
> if I missed something!). The bulk of work will be in mapping the ruby api 
> on top of the java api. We can help consult on areas that are not 
> straightforward once you do this. 
>
>  
>
> General recommendations on the approach:
>
> Use Java's advanced API instead of the stub API. That means things in 
> io.grpc instead of io.grpc.stub. Specifically, ManagedChannel and 
> ClientCall. You can refer to io.grpc.stub.ClientCalls and the generated 
> code 
> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fgrpc%2Fgrpc-java%2Fblob%2Fmaster%2Ftesting-proto%2Fsrc%2Fgenerated%2Fmain%2Fgrpc%2Fio%2Fgrpc%2Ftesting%2Fintegration%2FTestServiceGrpc.java&sa=D&sntz=1&usg=AFQjCNFDAzNMipYzwjwDBroR4KxAMxuSBg>
>  
> for inspiration/hints. Getting a working MethodDescriptor may be a bit 
> annoying, but after that point most things hopefully start coming together 
> since you could do Channel.newCall() which is very fundamental.
>
>  
>
> As far as the shims go, it may be doable but some items may be infeasible. 
> At that point, it would be good to discuss the specific points on this 
> thread and we can definitely help figure out.  Some areas such as 
> Call/Channel credentials APIs might be candidates for that. There are a 
> number of APIs for ruby channel objects that are specific to the C-core 
> (see options passable to channel constructors in 
> https://github.com/grpc/grpc/blob/c4f46018096a85f239ace283563ad5c192a6c433/include/grpc/impl/codegen/grpc_types.h#L152),
>  
> along with call credentials, channel credentials, etc. Possibly not 
> everything needs to be emulated, but a minimum of this surface would need 
> to be designed for us to review by the proposer of the gRFC (you) and later 
> implemented.
>
>  
>
> As a lower priority, consider decoupling this implementation from 
> grpc/grpc, it would be nice to land this in grpc-ecosystem eventually.
>
>  
>
>  
>
> Thanks
>
>  
>
>
> On Tuesday, June 6, 2017 at 3:44:01 PM UTC-7, Jason Lunn wrote:
>>
>> TL;dr: 123 of 145 unit tests pass; need help to move forward
>>
>> The proposal PR has been updated with notes detailing the current work in 
>> progress and a link to a proof-of-concept branch. A project member with 
>> experience with both the Java and Ruby implementations that could help 
>> describe how to canonically invoke the right combination of Java APIs to 
>> meet the expectations of the Ruby library would be greatly appreciated.
>>
>>  - Jason
>>
>> On Wednesday, February 15, 2017 at 11:59:31 AM UTC-5, Jason Lunn wrote:
>>>
>>> There is a GRFC <https://github.com/grpc/proposal/pull/13> to add 
>>> support for the JRuby <http://jruby.org/> interpreter, which runs on 
>>> the JVM.
>>>
>>> Please provide all feedback on this thread.
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"grpc.io" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/grpc-io.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/grpc-io/15289b2c-3ffc-4e42-84eb-e92ad7042528%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to