On Mon, Apr 9, 2018 at 8:39 PM, Sage Weil <sweil@xxxxxxxxxx> wrote:
> Should we
>
> 1- Print something else there even though it is not strictly correct?
> That would mean that something can't parse the (JSON) dump output and
> get the right answer.
>
> 2- Disallow binary data. This seems weak, but at least behavior would be
> consistent. We'll probably break some random out-of-tree users out there.
>
> 3- Use XML as the output format for this command?
>
> 4- Remove the 'dump' command entirely and make you get each item. There
> is still 'ceph config-key list' to get the keys you would need to
> individually get.
>
> All of these options kind of suck. Is there a better option I'm missing?
5) (I don't know about "better" but:) Encode all strings with e.g.
base64? Then at least the user of the json output must deal with
decoding the strings in a consistent way. Obviously that has the
unfortunate side-effect of making the json output completely human
unreadable.
Or, (6) output values as
"config-history/1/": {
"type": "string",
"value": "bar"
},
"config-history/1/": {
"type": "blob",
"value": "base64://ABCD=="
}
"config-history/2/": {
"type": "integer",
"value": 1
}
(Perhaps a last minute change to add blobs or maybe just dynamically
recognize them.)
> I'm feeling pretty let down by the collective industry decision to use
> JSON for all the things.
Indeed.
--
Patrick Donnelly
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
