thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Geyer (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (THRIFT-4535) Current state and future of .NET libraries ("csharp" and "netcore")?
Date Fri, 30 Mar 2018 14:51:00 GMT

    [ https://issues.apache.org/jira/browse/THRIFT-4535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16420573#comment-16420573
] 

Jens Geyer edited comment on THRIFT-4535 at 3/30/18 2:50 PM:
-------------------------------------------------------------

{code}
Folks stuck needing to support older frameworks like .NET 3.5.1 can continue to use Thrift
0.11.0 or earlier.  We shouldn't be scared to drop older language support because folks can
continue to use older Thrift to make it work.  One can use Thrift 0.7.0 client with a Thrift
0.11.0 server, for example, if it were truly necessary to support some ancient language level.
 So if you are using an older CentOS with an older mono, you might need to use an older thrift.
 That's reasonable.
{code}

I wasn't saying that. I was not saying that we should never drop support for older versions,
quite the opposite. What i I was saying is, that we should be careful with that decision.
There are people out there who are using interesting combintaions of tools. It's easy to say
"I know what the majority of users is doing" but it may a) simply wrong, and b) even a minority
of 5% are still quite a lot of users. We should absolutlely think about what versions we plan
to support with the next release and e.g. drop Net < 4.5 if that makes sense. I'm for it,
everything less to support can be one special case less. But I don't want to find myself in
a shitstorm because we overlooked something not being supported on CentOS, and you don't want
either, believe me. And yes, I picked that example very carefully and intentional.

{code}
This is all FOSS, so the notion of being "supported" at all is a best-effort community driven
exercise.
{code}

Correct.

{code}
Should I work on "csharp" and "modernize" it by taking stuff from "netcore"? 
{code}

+1 .

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. 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.

{code}
Has this already been tried and failed, resulting in the decision to create the new, distinct,
"netcore" code base?
{code}

Why are you continuing thinking that? Nobody failed here. The first version came in when netcore
was quite new. A lot of things have changed since, e.g. the project format to name just one.
There is no "predecessor" or "successor", they are both equally valid and alive.




was (Author: jensg):
{code}
Folks stuck needing to support older frameworks like .NET 3.5.1 can continue to use Thrift
0.11.0 or earlier.  We shouldn't be scared to drop older language support because folks can
continue to use older Thrift to make it work.  One can use Thrift 0.7.0 client with a Thrift
0.11.0 server, for example, if it were truly necessary to support some ancient language level.
 So if you are using an older CentOS with an older mono, you might need to use an older thrift.
 That's reasonable.
{code}

I wasn't saying that. I was not saying that we should never drop support for older versions,
quite the opposite. What i I was saying is, that we should be careful with that decision.
There are people out there who are using interesting combintaions of tools. It's easy to say
"I know what the majority of users is doing" but it may a) simply wrong, and b) even a minority
of 5% are still quite a lot of users. We should absolutlely think about what versions we plan
to support with the next release and e.g. drop Net < 4.5 if that makes sense. I'm for it,
everything less to support can be one special case less. But I don't want to find myself in
a shitstorm because we overlooked something not being supported on CentOS, and you don't want
either, believe me. And yes, I picked that example very carefully and intentional.

{code}
This is all FOSS, so the notion of being "supported" at all is a best-effort community driven
exercise.
{code}

Correct.

{code}
Should I work on "csharp" and "modernize" it by taking stuff from "netcore"? 
{code}

+1 .

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. 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.

{code}
Has this already been tried and failed, resulting in the decision to create the new, distinct,
"netcore" code base?
{code}

Why are you continuing thinking that? Nobody failed here. The first version camne in when
netcore was quite mnew. A lot of things habve changed since, e.g. the project format to name
just one. There is no predecessor or successor.



> 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)

Mime
View raw message