[
https://issues.apache.org/jira/browse/THRIFT-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386185#comment-17386185
]
S.P. IDEMIA commented on THRIFT-5442:
-------------------------------------
Yes, no problem with the naming convention, I just feared I might have
overlooked something when I checked .NET Standard version since I searched
specifically for {{send_\*}}/{{recv_\*}}.
Understood the fact that we use a non-documented feature in 'csharp' target,
this makes sense to consider that as a new feature for 'netstd'.
As a side note, we also use it in C++ and Python and some other users might use
it in some other languages as well so when we propose the patch, it could be a
good idea to document that precisely.
This way, it would allow some languages that don't already have it (I think
'rust' is in this case, for instance) to reproduce the feature in consistent
manner.
Anyway, thanks for the info, we'll see how to proceed next.
> Separate client service calls into send/recv methods and make them public
> -------------------------------------------------------------------------
>
> 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)
