Split up gRPC C# package into API vs native implementation #1
Comments
|
CC @JunTaoLuo |
|
I assume this work will be done in grpc/grpc and this is just a tracking issue? |
|
@JunTaoLuo yes, I thought it's easier to track here (so we can easily create projects/milestones) than in grpc/grpc repo that has many other open unrelated issues and it would be easy for stuff to fall between the cracks. |
|
I've finished my first pass through all the types in Grpc.Core and I've marked what I think should be included and excluded from Grpc.Common as well as the reason behind the decisions. @jtattermusch can you check whether these concur with what you have? Some of the decisions will probably warrant more explanation but I intend to prototype a Grpc.Common package tomorrow with the types listed here and see if it is sufficient for building Grpc.AspNetCore.
|
|
Once we decide the destination package name (I believe |
|
Either Grpc.Core.Api or Grpc.Core.Common are fine with me. And as we get further into development we can always change it before shipping the first non-prerelease version. @jtattermusch it would be great if you could go ahead with this. Please ping us in the grpc/grpc PR so we can take a look. |
|
@JunTaoLuo I saw that you are also trying to come up with a prototype of the split. There will need to be some modifications to some of the existing classes to be able to separate them out, but I think I'll be able to solve that. |
|
Perfect! :) I was re-organizing my sample to facilitate the move to the official repo once we have write access and I thought it'd be a good opportunity to prove out that the list that I came up with is necessary. Once the split package is available, there won't be a Grpc.Common/Api in the grpc-dotnet repo. Also, before we commit to the list, let's consider #21 first since that might reduce the types we need. Also, should we be eager with moving types to Grpc.Common/Api? For example, should we move the logging related types to it right away? Or should we wait until we write the adapter? |
|
@JunTaoLuo moving the types around is going to have some challenges around test infrastructure and package building in the grpc/grpc repository, so I wanted to start with the split early to finish it on time. Otherwise, once we confirm that the APIs allow the split without API breakages (I think we're close), there's no rush with the split (we can just depend on Grpc.Core) - we just need it to be ready for the first official release. |
jtattermusch
pushed a commit
that referenced
this issue
Feb 1, 2019
Re-organizing sample based on expected packages
|
I think with grpc/grpc#17889 merged this is completed? I'm going to close this, but feel free to re-open if you think there is still more work to be done. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For the asp.net core integration, we will need to depend on Grpc C# APIs, but we don't want to pull the native dependencies. We need to come up with a way to split the packages into managed-only (mostly APIs) and native interop.
The text was updated successfully, but these errors were encountered: