[
https://issues.apache.org/jira/browse/THRIFT-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16420621#comment-16420621
]
Christian Weiss commented on THRIFT-4535:
-----------------------------------------
Thanks again for the quick response!
I've had a closer look at the code in the meantime and I identified the
following main differences. I've not been comparing method implementations
though, so I don't know if "netcore" e.g. fixes some implementation details.
* "netcore" reorganizes files and namespaces - e.g.
** Thrift.Protocol -> Thrift.Protocols; a new Thrift.Protocols.Entities
** Thrift.Transport is split into Client & Server
** *Proposed solution:*
*** DO keep the old structure and namespaces. While the "new" structure might
be nice, there's no real benefit and it breaks everyone.
* "netcore" uses different code styling - e.g.
** Some methods have been renamed from camelCase to PascalCase
** Some interfaces have an "I" prefix.
** Parameters, variables have been renamed (to not contain abbreviations)
** *Proposed solution:*
*** DO rename methods from camelCase to PascalCase. This is a breaking change,
but having camelCase for methods is completely untypical for C#.
*** DO NOT append "I" prefix to interfaces. This would break too much (e.g.
TBase, ...)
*** DO rename variables and parameter names to not contain abbreviations. This
does not break anything and helps for readability.
* "netcore" has dropped a few transports and added others - e.g.
** Transports that depend on "System.Web" (as that's not available in .NET
Core) and the Silverlight transport
** New transport that depends on "Microsoft.AspNetCore"
** *Proposed solution:*
*** DO keep the old transports but only make them available on supported
platforms (via #if cases).
*** DO drop the Silverlight transport. Silverlight is dead. If someone really
complains about this, we can try to add it again.
*** DO NOT add the new ASP.NET Core based server to the main assembly. The
main Thrift library should not depend on a specific web framework. Instead, the
server should be delivered as a separate package - e.g.
Thrift.Server.AspNetCore.
* "netcore" makes heavy usage of async/await.
** While this makes sense in some places, I was surprised to see async/await
being used that much in "Protocol". As each "await" generates an internal state
machine, I would think that doing this for pretty much every character must be
much slower than the current code in "csharp". Am I wrong here and has this
been proven faster?
** *Proposed solution:*
*** DO carefully migrate async/await by doing some benchmarks and only apply
it where it is useful.
* "netcore" targets .NET Standard 2.0
** This does is too new and doesn't support older but popular versions of some
platforms.
** *Proposed solution:*
*** Convert "csharp" to new project format and target at least
"net45;netstandard1.6;netstandard2.0". This gives us platform support for .NET
4.5+, .NET Core 1.0+, Mono 4.6+, Xamarin and UWP.
Given that I now know more about the code base, let me address your comments.
{quote}In fact, that's a nobrainer decision. The csharp part was there long
before netcore (and it was the origin of it), so netcore should be the victim
and be merged over to csharp.
{quote}
I agree. There's no need for unnecessary breaking changes (e.g. namespace
changes etc).
{quote}And please, try to not scare people with whatever "modernize" means
exactly, and have an eye on compatibility. Nobody wants to rewrite the whole
application just because of an RPC library update.
{quote}
I thought that "netcore" would have more feature differences but as it does
not, the main challenge is the usage of async/await. We should discuss any
changes here as this definitely has an impact on users. However, we can also
keep the synchronous versions at some places to let the user choose which one
he wants to use.
{quote}There is no "predecessor" or "successor", they are both equally valid
and alive.
{quote}
Even after having looked at the code, I do not really understand that if you've
never intended to deprecate one. The two code bases are so similar that
maintaining two versions seems very painful/unnecessary. And given that there
is no release of "netcore" (at least I haven't seen one) I'd say it's not
really "alive" yet. :)
Anyway, What do you think about my proposed solutions?
> Current state and future of .NET libraries ("csharp" and "netcore")?
> --------------------------------------------------------------------
>
> Key: THRIFT-4535
> URL: https://issues.apache.org/jira/browse/THRIFT-4535
> Project: Thrift
> Issue Type: Question
> Components: C# - Library, netcore - Library
> Reporter: Christian Weiss
> Priority: Major
>
> Hi,
> We are trying to use Thrift in one of our projects but we ran into some very
> fundamental issues:
> * The "csharp" project does not target ".NET Standard" and there's only a
> very old release on nuget.org ( if [https://www.nuget.org/packages/Thrift/]
> is the official one).
> * The "netcore" project does target ".NET Standard" but there's no release
> yet ( https://issues.apache.org/jira/browse/THRIFT-4512 ) and it also has a
> dependency on ASP.NET Core (
> https://issues.apache.org/jira/browse/THRIFT-4534 ) which makes it unusable
> in non-web projects.
> I'm wondering why there even are 2 separate projects for .NET? It's important
> to understand that ".NET Core" is not a new programming API - It's just a new
> platform - very similar to Silverlight, Mono, Windows Phone. This means that
> it would also be possible to support .NET Core and the new ".NET Standard"
> (which represents a common set of APIs for all platforms) with the existing
> "csharp" project.
> Was this a deliberate decision - e.g. to make the "netcore" code the official
> successor of the "csharp" code?
> Would you be interested in merging the code back into one library? I'd be
> willing to help if you want!
> It would be great to get one proper, up to date and official .NET library
> soon as there's already quite a lot of weird forks on NuGet.org:
> https://www.nuget.org/packages?q=Thrift
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
