Exclude fetch specification from Scripting API

[danielpeintner]

We had discussions around "whether fetching a TD should be part of the Scripting API" (e.g., for consuming a thing). This issue is meant to summarize the discussions and propose text which goes into rationale.md for traceability.

Fetching a TD from a resource might as easy as providing an URI. Having said that, even in this presumably simple case the URI might be an http-uri, a coap-uri, or a data-uri. Probably not all scripting API implementations support all the different kinds of URIs. Other fetching mechanisms might require additional information/credentials etc to access the resource.

Hence it seems reasonable to sketch possible ways how a TD might be fetched (e.g., browser fetch) in the scripting API document without making any normative statements how this is going to happen. The assumed starting point is the ThingDescription (TD) itself (e.g., in form of a JSON document, object, ...).

I hope this summarizes the discussion. Please make comments below and we will update the text accordingly.

[zolkis]

I think for fetch we need a URL.

I agree with the reasoning above, but IMHO the proposal is not the only possible or necessary outcome.
Fetch() is a rather low level API, covers much more ground than the "fetch a TD" use case and depending on the case, it might be cumbersome to write the correct code to fetch a TD.

For this, developers will need detailed knowledge about communicating with the other end: method, body, headers, credentials, mode, options etc. Once developers have to learn that knowledge how to do a fetch, they could as well make POST, PUT, GET etc calls themselves to interact with Things (since they are already familiar with the HTTP client library or Fetch), and they will have no need for the Scripting API. Why should they trust a middleman (Scripting implementation) when they can totally control what they already understand, with the low-level API they are using for fetch?

Typically (IMHO) it will be not the developers, but the solution makers who will have that knowledge. Encapsulation for developers will happen on a higher, solution level, which will fragment things just as it happened with other IoT approaches (of course, solution level encapsulation could be standardized on its own, for instance using HTTPS+WSS if we speak about a W3C standard). That is one thing that certainly makes sense, and it is the necessary end of the logic that starts with the statement "do the fetch yourself".

Since the Scripting API has been mainly about the convenience of using the TD paradigm on Thing level (to start with), the question becomes whether is it acceptable to include a convenience method that will try to fetch a TD from a URL for most common scenarios and fail if it cannot. Then the developer could use lower level APIs to fetch a TD. IMHO starting with a TD URL rather than a TD is a better web-developer story.

I would argue that in majority of cases an implementation could actually figure out quite well how to fetch a TD on a given platform (browser Fetch API, or a HTTP client library etc).

Provisioning (including script manifests, credentials etc) has been deemed out of scope for Scripting. This means the runtime/script has to be provisioned to be able to interact with Things: part of that comes from the TD, and other part from device provisioning. If credentials are needed during a fetch, an implementation should be able to figure it out based on provisioning, or pop up a dialog when possible, or fail (then, as said, one may try a lower level API or give up).

[zolkis]

Fixed by #165