Simplification of interface InteractionOutput

[danielpeintner]

While looking again at the interface InteractionOutput definition I felt it could be very much simplified as follows:

interface InteractionOutput { 
  readonly attribute Form? form;
  readonly attribute DataSchema? schema;
  any value;
}

Let me try to explain why I think this would be sufficient.

• form may provide hints about the form used
• schema may provide information about the actual type (if various types are possible)
• value can be directly processed (without promises)

The additional ArrayBuffer, ReadableStream, boolean dataUsed to me makes it more complex than needed.
I am happy to hear your push-back and your arguments :-)

To be honest, I don't have a very strong argument. I just feel scripting should be simple to use...

[relu91]

I'll start from this hypothesis:

• We need to cover use-cases for stream-based reading and writing. I still think this is really important for an IoT based API as not all devices could afford to read everything they receive from the memory. Not mentioning the range of data types that are stream based in nature; like a real-time video feed.

Having said that we could try to cover everything with the interface you're proposing. Simply put the runtime could return a ReadableStream in the value field when it cannot provide a JavaScript object from the network response (i.e., the form does not contain a DataSchema or the response is not a convertible mediaType). However, there are still some corner use cases when the runtime cannot predict if the application script would prefer a Stream or the parsed value:

What if the application knows that it is running on a constraint device and whats to carefully dimension the reading buffer so that it can accomplish another acquisition task?

Runtimes could detect low memory conditions but the applications would not have control over this decision; they would receive randomly a stream or a parsed value as a response accordingly to the current memory conditions of the device.

Probably this is a corner case... So I could still accept an API based on your suggestion as a sub-optimal solution to increase the simplicity of the platform. However, we must not drop the support for a streaming-based interaction between things.

[danielpeintner]

Thanks @relu91 for your feedback!

However, there are still some corner use cases when the runtime cannot predict if the application script would prefer a Stream or the parsed value:

The application can still not prefer one over the other. It is the the runtime that decides what gets returned.
Wouldn't it than be better to have something like readPropertyAsStream() (Note: I am not arguing for it ;-) )

[Edit: I think there is some freedom in interpretation here. Does application mean the application in the runtime or on the consumed side]

[zolkis]

The use case we agreed was like this:

• the bindings will use the Fetch API or similar library to get a Fetch Response object or similar, that includes the Body mixin or similar.
• if the impl can figure out the content type and/or data schema, go ahead and consume the input streams and expose the value as convenience. This is the most common case, and does not differ from the any that's been used before, and now suggested for using again.
• otherwise leave value undefined and the input streams unconsumed for the app could handle it. We do need this to cover use cases that are not handled by the any that's been used before.

This is pretty straightforward if the impl is using the Fetch API or similar library. Also, it's the most generic and convenient for apps.

In Web APIs the usability/user convenience has higher priority than ease of implementation, but in this case the Body mixin is a given, so there is not even any complication, just standard interfaces.

[danielpeintner]

Scripting API Call 2021-02-01

• it was found important to support streams (otherwise many use cases would suffer)
• simple implementation that only support the value() function can still do so reporting a "not supported error" IF anything else is provided
• we should make 100% clear that the the value() function can ONLY report basic JSON types (see DataSchemaValue in TS should not be any #296) and not ReadableStream, ArrayBuffer, et cetera
  • see https://w3c.github.io/wot-scripting-api/#the-value-function : I think step 2. can be improved like "If the value of the [[value]] internal slot is not undefined and of type string or number or array or object or null, resolve promise with that value and abort these steps".
  • We can also refer to DataSchemaValue which describes in prose the valid types

[danielpeintner]

I think this issue has been settled by now and I will close it.