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

S.P. IDEMIA edited comment on THRIFT-5442 at 7/23/21, 5:14 AM:
---------------------------------------------------------------

It is part of the public interfaces in the generated code.
In the provided example, the generated code appears in Thrift/MultiRecv 
directory.

In this case, we can see:
- line 104: The single function for 1-call-1-reply usage {{public 
upgrade_progress firmware_upgrade(byte[] firmware)}}
- line 129: The call-only part {{public void send_firmware_upgrade(byte[] 
firmware)}}
- line 140: The reply-only part {{public upgrade_progress 
recv_firmware_upgrade()}}

Edit: I see that we have a different naming convention in the Silverlight case:
- line 91: {{public IAsyncResult Begin_firmware_upgrade(AsyncCallback callback, 
object state, byte[] firmware)}}
- line 96: {{public upgrade_progress End_firmware_upgrade(IAsyncResult 
asyncResult)}}

I checked in the generated code for .NET standard, neither of the conventions 
appear and the {{firmware_upgradeAsync}} method is clearly doing both parts 
with lower-level APIs.


was (Author: spiisf):
It is part of the public interfaces in the generated code.
In the provided example, the generated code appears in Thrift/MultiRecv 
directory.

In this case, we can see:
- line 104: The single function for 1-call-1-reply usage {{public 
upgrade_progress firmware_upgrade(byte[] firmware)}}
- line 129: The call-only part {{public void send_firmware_upgrade(byte[] 
firmware)}}
- line 140: The reply-only part {{public upgrade_progress 
recv_firmware_upgrade()}}
 

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

Reply via email to