RE: JSON-serializable object

From: Anne van Kesteren [mailto:annevk@annevk.nl] 

> On Wed, Nov 16, 2016 at 7:17 AM, Marcos Caceres <marcos@marcosc.com> wrote:
>> However, it doesn't define how a UA actually would check the above...
>
>Yeah, that seems like the main problem. No defined processing model.
> Is there an open issue? IDL could define something here in theory, but I don't think we've had this particular set of constraints before, whatever the processing model may be. There's a couple APIs that return JSON, but I don't know any that accept it as input (whatever that means). So I'd think that the processing model should be sorted first and then maybe it can be uplifted to IDL if it becomes a common pattern.

I agree it is premature to solve this in IDL.

I don't think this has much to do with structured clone. My understanding is the payments spec mostly cares about being able to send something over the wire in a JSON serialized format, which is a much tighter restriction than structured clone.

I think this is simply defined as Marcos put in his original message. A JSON-serializable object is an object on which running JSON.stringify does not throw an error. As such, ideally all algorithms in the spec should be recast to something like:

1. Let _string_ be the result of JSON-stringifying _idlObj_, as if by the built-in JSON.stringify function passing _idlObj_ converted to an ECMAScript value. If doing so would throw an exception, then, let _string_ be null.
2. If _string_ is null, then
   1. ... handle the not-JSON-serializable case...
3. Otherwise,
   1. ... handle the JSON-serializable case...
   1. (Don't forget to use the Encoding Standard to convert _string_ to bytes.)

I think that the only real way that we could improve the situation is to define an abstract operation in ES, e.g. JSONStringify(obj), which takes care of the "as if by..." clause. That's more of a job for ES than it is for IDL.

Received on Wednesday, 16 November 2016 14:42:46 UTC