On 19/10/2015 17:46, Daniel P. Berrange wrote: >> > The difference is that guest-file-read/write have the payload in JSON; >> > for file-based secrets the payload is not JSON. > For non-file based secrets though, the payload *is* in the JSON, > and per the cover letter, I actually anticipate passing all > secrets inline in the JSON and only using the file backend for > loading the initial master key. This avoids the need to do > file handle passing and/or create lots of temporary files, when > hotplugging resources. > > > So I think that "binary" (which is the default anyway) would fit all the > > usecases (direct over JSON, file-based, direct over command line). > > Direct over JSON would be limited to valid UTF-8, but that's just a > > limitation of the transport. > > I don't think that's actually an acceptable limitation - I want the > inline data passing to be fully usable for non-UTF-8 data too.
Of course, there's base64 for that. On the other hand, I think there's no reason for unencoded file-based data passing to be usable for UTF-8 data only. Paolo
