[
https://issues.apache.org/jira/browse/THRIFT-5442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Geyer resolved THRIFT-5442.
--------------------------------
Fix Version/s: 0.15.0
Resolution: Fixed
{quote} 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.{quote}
Feel free to discuss, open appropriate ticket(s) if it makes sense & send
patches/PRs.
> 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
> Assignee: Jens Geyer
> Priority: Major
> Labels: features
> Fix For: 0.15.0
>
> Attachments: multi-recv.7z
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> 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)
