Enhancement: In REPL mode read bytes from file

[BenSlabbert]

Thanks for an awesome tool :)

While working on a new feature I needed to be able to send binary data. The existing support using JSON and base64 encoding is great, however I feel we can improve the REPL with the following change:

When prompted for TYPE_BYTES allow the user to specify a path to a file which is then read in.

For example:

data (TYPE_BYTES) => file:///full/path/to/file.txt

I have also created a pull request: #280 with this suggested change.

[ktr0731]

Thanks for proposing a new feature.
I'm sure it's a great feature that will greatly enhance Evans more user-friendly!

I want to suggest some points about implementation.
First, "file" URI scheme defined in RFC 8089 doesn't allow relative path, so this testcase must read from /proto.go, not ./proto.go.
Also, we assume that introduce the feature with the strict "file" URI scheme, it's inconvenient because we cannot specify files by using relative path representation.

So, how about specifying files by using path/filepath representation just like ./proto.go? I think it's straightforward usage to almost users.
However, by introducing this change, it's not able to specify a file path as "string". So, we should implement some additional things such that disable file path interpretation (maybe a flag?).

[BenSlabbert]

Great suggestions thank you!

I agree using a relative filepath will be better instead of the full path in terms of usability.

with regards to:

However, by introducing this change, it's not able to specify a file path as "string". So, we should implement some additional things such that disable file path interpretation (maybe a flag?).

should we add a flag that will by default interpret the input to TYPE_BYTES as a relative file path?
is this for each REPL session or for each grpc service call?

[ktr0731]

should we add a flag that will by default interpret the input to TYPE_BYTES as a relative file path?

We should, it's better than adding a flag that disables flag interpretation 👍

I think it's better to define a flag that belongs to the REPL call flag set to narrow down the influence of the flag. If there is an inconvenience, it can be redefined in a larger scope.

[BenSlabbert]

I will update the PR accordingly :)

[BenSlabbert]

PR updated :)

[ktr0731]

Merged in #280