On Mon, Oct 19, 2015 at 06:28:26PM +0200, Paolo Bonzini wrote: > > > On 19/10/2015 18:24, Daniel P. Berrange wrote: > > The input format, eg the encoding of the data=XXXX value, or the contents > > of the file, and the output format, which is that required by the consumer > > inside QEMU. We convert between the two. eg you can provide data in base64 > > even if QEMU ultimately needs to use it in plain utf-8 format, or > > vica-verca. > > Right. In the end QCryptoSecret only needs to provide a raw output; > converting it to something else, and possibly applying restrictions such > as UTF-8, should depend on the user. Of course the API can include > helper functions for common restrictions, but in general a "secret > storage" module is independent of them. > > > IIUC, you're suggesting that for the input format, the data=XXX value > > should allow a choice of utf8 or base64, while the external file could > > just take raw or base64 data. That's easy enough to wire up - just add > > a 3rd option to the format enum and make raw be the default for files. > > Almost. > > I am also saying that the utf8 case for data=XXX actually should be raw, > because utf8 is just a limitation of JSON and not of the data=XXX > interface. Non-UTF8 data=XXX would then be accepted for the -object > command line option.
Ah ok, I see what you mean now Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
