- From: Marcos Caceres <marcos@marcosc.com>
- Date: Tue, 15 Nov 2016 22:17:04 -0800
- To: public-script-coord <public-script-coord@w3.org>
The Web Payment spec has the following concept defined [1]: > The term JSON-serializable object used in this specification means an object that can be serialized to a string using JSON.stringify and later deserialized back to an object using JSON.parse with no loss of data. See [2] for example in prose. However, it doesn't define how a UA actually would check the above... apart from basically calling: ```JS try { JSON.parse(JSON.stringify(obj)); } catch(err){ throw new Error("Not a JSON-serializable object"); } ``` The concept of a "JSON-serializable object" seems somewhat related to structured clones/transferables (kinda, sorta... though of course clones support some more sophisticated types/interfaces). I'm wondering if public-script-coord can help (either through WebIDL or TC39) with creating something more concrete that implementations can rely on. I'm pretty sure this has been discussed before numerous times, but I can't recall what conclusion we reached and if this is already a solved problem. Kind regards, Marcos [1] https://w3c.github.io/browser-payment-api/#dfn-json-serializable-object [2] For example, "Set the details attribute value of response to a JSON-serializable object containing the payment method specific message that will be used by the merchant to process the transaction. The format of this response will be defined for each payment method." You can see numerous instances of JSON-serializable object throughout the spec.
Received on Wednesday, 16 November 2016 06:17:39 UTC