Modifiers to load from file and encode - ordering, apply to value vs key.

[ferrouswheel]

I feel that the file@ and b64encode@ modifier syntax is a bit unintuitive:

Example from dev portal:

'{"image_type": "jpg", "file@b64encode@image": "1.jpeg"}'

One, I would have expected the modifer on the filename 1.jpeg.

Two, the order seems backwards, I think the file should be loaded, and then it is encoded. Thinking of them as operators that apply to the RHS, and applying the modifiers to the filename, I think this makes more sense:

'{"image_type": "jpg", "image": "b64encode@[email protected]"}'

As it stands it feels like the modifier is saying b64encode the filename, then open that base64 file.

It also doesn't obfuscate the parameter names.

(I couldn't find an issue that described where this was introduced, otherwise I would comment there.)

[astroseger]

1. Unfortunately it is impossible to apply modifiers to the value without restriction to the content of value (maybe user indeed wanted to pass "b64encode@[email protected]" as a string). So modifiers should be applied to the key (we cannot have @ in the key name, so we are safe here).
2. We can change order: so it will be '{"image_type": "jpg", "b64encode@file@image": "1.jpeg"}'

[ferrouswheel]

I think it's easy enough to escape an @ symbol, the same way strings are escaped in programming languages etc.

It'd be annoying for some people, but the json -> protobuf mechanism is a hack for experimentation anyhow. I think anyone using snet seriously should be constructing the pb message themselves and setting the metadata on the grpc call.