[http-client-rust] Support File to represent file input and output in request/response body Implementation

[lmazuel]

[jhendrixMSFT]

We've been achieving this via bytes type with bytes encoding. I will say that using file is cleaner. What does it mean for bytes/bytes, are we going to deprecate that? Or do we end up with two ways to say the same thing? If so, which one do we recommend people use? Are there any subtle differences?

[heaths]

I don't like File, actually. It implies, well, a file. We're sending/receiving bytes or a stream, if you will. .NET doesn't use "file" either, but "stream". @lmazuel what is driving this requirement and why don't other languages do this?

As for streaming to/from files, we already have a pattern and document it. It doesn't require a separate type so I don't know how we'd inject "File" into the current workflow.

[lmazuel]

This is a low priority item. It just happens it's possible to write in TypeSpec, and we got this issue. Roughly as an input, it means accept bytes or file descriptor. As an output, return bytes or stream. It's a way to say "Don't look into it, don't try to deserialize or be smart about it, the content doesn't matter to you"

For Python, as input we will take Union[IO, bytes], and output we will use our regular bytes behavior, which is bytes in the general case, and stream if stream=True

[heaths]

Thanks for the clarification. That's not actually idiomatic to Rust for file APIs. They don't deal in "streams" (sadly in some cases), so I think our existing bytes signature are sufficient. @jhendrixMSFT, @LarryOsterman, @RickWinter what do you think?

[LarryOsterman]

I'll be honest and say that I don't see the need to add a new abstraction to express "these are Bytes read from a file" which is somehow different from "these are Bytes read from the network".

If we do encounter a File construct in TSP, we should be able to express this as Bytes, unless there is some additional elements associated with File beyond what Laurent just said (for instance, if we're expected to be able to open or close the file).