Ping ? Do we have any update on the status of https://github.com/grpc/proposal/pull/13 and the JRuby effort in general ?
On Monday, March 6, 2017 at 2:04:53 PM UTC-8, Jason Lunn wrote: > > 1) I agree that a Java wrapper is preferred, and I'd contemplate a JNI > approach only the wrapper approach hit some unsurmountable roadblock > 2) A separate repository requires overhead and introduces opportunities > for breakage. As I said before, a single repo approach helps avoid breaking > behavior from slipping into the C implementation. It should also make it > less likely that a gem update is released for the C derived platforms > without a corresponding update for the JRuby variant. > 3-5) Per Mike's feedback about the Google Cloud gem's requirements, I'd > want to get all the existing tests to pass that are needed to make a viable > client, and I'd be willing to settle for raising an exception that the > operation is not supported on the rest of the API as a starting point. The > eventual goal would be to get complete API compatibility, but a client-only > approach would unblock the use of the Google Cloud by JRuby applications > the fastest, and that is my core motivation. > > I'm willing to contribute a proof of concept PR into the existing GRPC > repository. I haven't started such a branch yet, as I didn't want to start > such an effort before I got consensus that such a contribution would be > welcome in principle, so I have yet to look at the API surfaces in general. > > Lastly, I'm at a conference this week, so please accept my apologies if I > am not responsive until next week. > > - Jason > > On Thursday, February 16, 2017 at 3:17:42 PM UTC-8, [email protected] > wrote: >> >> Hi Jason, >> >> Thanks for sending this proposal, I took a look and had some comments: >> >> 1) As per the proposal, I think that the recommended approach is indeed >> go down the path of a java library wrapper. JNI wrapping is another >> possibility, but we should first investigate whether the Java wrapper is >> not possible before considering it. >> 2) IMO the jruby implementation can live in a separate repository and I >> would recommend this to start with. In the future, when the wrapped >> implementation is stable and passes interop tests we can consider merging >> it into the main repo. I would recommend starting this work outside of the >> main gRPC repo. The grpc-ecosystem org <http://github.com/grpc-ecosystem> >> is a good candidate. This will allow for maximum flexibility. >> 3) It would be useful to define some shallow tests that cover the API. >> Such tests should be added to the existing Ruby implementation first, and >> can then be used to ensure that the jruby implementation conforms. See >> https://github.com/grpc/grpc/blob/master/src/python/grpcio_tests/tests/unit/_api_test.py >> >> for a starting point. I must reiterate that this type of testing is very >> shallow and is not sufficient in itself, but a good addition to the interop >> tests. >> 4) For any gRPC implementation, we need to ensure that the interop tests >> pass. See https://github.com/grpc/grpc-java/tree/master/interop-testing, >> https://github.com/grpc/grpc/tree/master/src/ruby/pb/test and >> https://github.com/grpc/grpc/blob/master/doc/interop-test-descriptions.md. >> The jruby implementation needs to pass these in order to be considered >> conforming. We recommend re-using the ruby interop test suite with the >> jruby wrapper to the extent possible, independent of the java suite (of >> course, these can be leveraged as needed). The nice thing is that if the >> APIs fully conform, the ruby interop tests should just pass. >> 5) Given the difference between Java and C stacks, there may be API >> incompatibilities that might not be surmountable, especially in situations >> where the C core implementation specifics is directly exposed upward. Such >> situations need to be quantified and further down the line, we can decide >> how to tackle them and weigh the cost of doing just that vs a full JNI >> implementation. >> >> Some minor comments on the proposal doc itself: >> >> 1) Please add details on implementation ownership, so that it can be >> discussed. Its unclear if this is something that the proposer is signing up >> to implement, is that the plan? >> >> 2) Could you please update the proposal to cover the implementation >> approach in more detail based on some of these points. Ie: Location of the >> prototype repo, some discussion on the API surfaces that need to be >> conformed to and potential areas you have identified as problematic. This >> can go hand in hand with a prototype of the java wrapped approach so that >> we can tackle issues as they happen. >> >> >> Thanks! >> Kailash >> >> >> >> >> >> >> On Thursday, February 16, 2017 at 10:36:25 AM UTC-8, Mike Moore wrote: >>> >>> On Thu, Feb 16, 2017 at 9:08 AM, Jason Lunn <[email protected]> wrote: >>> >>>> It has probably been a decade since I had a reason to try to use JNI. >>>> Does anyone have any experience building Gems using that approach? Would >>>> it >>>> be the case that there would be one JAR per supported platform ( >>>> x64-mingw32, x86_64-linux, universal-darwin, x86-mingw32), or would it >>>> be a fat jar that include multiple JNI wrappers? >>>> >>>> I am not clear on what capabilities of the existing gem are needed to >>>> satisfy the dependency of the Google Cloud gem (which is my personal >>>> motivation to see this move forward). Maybe Mike Moore knows better if the >>>> client side would be enough? >>>> >>> >>> The Google Cloud gems are clients only, and so supporting the >>> client-half of GRPC would be sufficient for our use of GRPC. >>> >>> >>>> I think I prefer to see the JRuby support sit alongside the existing >>>> Ruby code in the same repository, and tested in a consistent way. This >>>> will >>>> help avoid breaking behavior from slipping into the C implementation that >>>> isn't observed until someone thinks to update the other repo. It should >>>> also make it less likely that a gem update is released for the C derived >>>> platforms without a corresponding update for the JRuby variant. >>>> >>>> On Wednesday, February 15, 2017 at 1:30:59 PM UTC-5, [email protected] >>>> wrote: >>>>> >>>>> As has been noted before, I think this would be possible by doing a >>>>> pure implementation, wrapping the java client, or with a JNI wrapper over >>>>> the C-core (these implementations probably end up relatively different >>>>> from >>>>> C-wrapping grpc-ruby). >>>>> >>>>> Actually one thing hasn't been noted yet: If only a client-side >>>>> library is needed, then perhaps the jruby-platform target could only need >>>>> to emulate the client-half of the c-wrapping grpc-ruby (would probably >>>>> simplify things). >>>>> >>>>> As for where the project could live though, one option is it could go >>>>> into the same grpc repo as current grpc-ruby. Another is it could be done >>>>> entirely as a third party project in its own repo, for which we could >>>>> give >>>>> some guidance. >>>>> >>>>> On Wednesday, February 15, 2017 at 8:59:31 AM UTC-8, 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/ed0b1078-7209-46af-9ef8-4df946be8059%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
