[
https://issues.apache.org/jira/browse/THRIFT-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386021#comment-17386021
]
Jens Geyer commented on THRIFT-5442:
------------------------------------
First, you are relying on undocumented behaviour. Unfortunately the send/recv
methods were public in csharp so they could be legitimately used from the
outside, nevertheless it is still undocumented stuff.
Second, this surely can be changed in a way that fits your particular needs
better. If you mind to send a pull request, I will happily review it.
The naming convention in C# were different for several reasons. The distinction
between async and non-async has been dropped with netstd, because there is no
non-async anymore at all, so it would be absolute nonsense to add "Async"
postfixes just to follow an (now outdated) naming convention that even MS does
not follow anymore with new APIs.
> Missing feature for migration from 'csharp' to 'netstd' target
> --------------------------------------------------------------
>
> Key: THRIFT-5442
> URL: https://issues.apache.org/jira/browse/THRIFT-5442
> Project: Thrift
> Issue Type: New Feature
> Components: netstd - Library
> Affects Versions: 0.14.0, 0.14.1, 0.14.2
> Reporter: S.P. IDEMIA
> Priority: Major
> Labels: features
> Attachments: multi-recv.7z
>
>
> The 'csharp' library and target have been deprecated in version 0.13.0, and
> removed in version 0.14.0, with the indication that the 'netstd' target is
> its replacement.
> However, the netstd target is missing some features that were present in the
> 'csharp' target, which can make the migration difficult or impossible.
> One such use case is when a server sends a sequence of replies for a single
> command call by a client, e.g. to provide a stream of live data or progress
> updates without constant polling from the client.
> Here is a minimal example, where a device regularly sends information about
> its firmware upgrade process, to provide a status display on the controlling
> client, and to indicate when the device can be rebooted (on the new firmware).
> {code:c++|title=minimal.thrift}
> struct upgrade_progress {
> 1: required i8 percent;
> 2: optional string current_action;
> 3: optional bool finished = false;
> }
> service multi_recv
> {
> upgrade_progress firmware_upgrade(1: binary firmware);
> }{code}
> Here, the device (server) sends multiple replies, all of type
> `upgrade_progress`, until the operation ends (for whatever reason).
> On the PC (client) side, depending on the client software, we use either the
> 'csharp' or 'cpp' targets, relying on the public {{client.send_command_name}}
> and {{client.recv_command_name}} methods which are generated alongside
> {{client.command_name}}, allowing an easy handling of this kind of process:
> {code:c#|title=Program.cs}
> client.send_firmware_upgrade(firmware);
> do
> {
> var res = client.recv_firmware_upgrade();
> // Display progression using res.Percent & res.Current_action
> upgrade_done = res.__isset.finished && res.Finished.Value;
> } while (!upgrade_done);{code}
> Unfortunately, the 'netstd' target does not generate these methods resulting
> in an incomplete replacement of the 'csharp' target.
>
> [^multi-recv.7z] contains the complete client for the described interface.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
