WoT.consume(USVString url) sufficient for consuming things?

[danielpeintner]

WoT used to have methods to consume ThingDescriptions based on a given URL but also based on a stringified JSON (object). The latter one has been removed.

Hence,

• do we still see use-cases that should allow for consuming a stringified TD?
• is it a solution to wite a local file instead that can be passed as URL?
• use data uri (e.g., 'data:application/json;charset=utf-8, ...')

The only down-side I see with these solutions is that implementations need to have protocol support for http, file, data, ... while a plain string processing is supported out-of-the-box.

[zolkis]

We could theoretically split the fetch() and consume() parts,

Promise<USVString> fetch(url);  // or fetchDescription
Promise<ConsumedThing> consume(USVString description);

Alternatively, we could have a combined argument type:

typedef (ThingInit or USVString) ThingSource;
Promise<ConsumedThing> consume(ThingSource source);

then we could say
wot.consume("https://mythings.com/mything1").then((thing) => { ... });

or

wot.consume({ url: "https://mythings.com/mything1"}).then((thing) => { ... });

or

wot.consume({ 
    contentType: "application.json",
    description: "{ \
          // here come the TD specified e.g. as JSON \
    }"
  }).then((thing) => { ... });`

where ThingInit is defined as in the spec (name, url, description properties), plus a contentType property for the TD serialization. The client code can also give a local (user defined) name for the consumed thing.

[danielpeintner]

I like the idea of separating the processing steps to fetch() and consume().

The only "update" to your proposal for me would be changing the signature of consume to

Promise<ConsumedThing> consume(ThingDescription description);

We don't know yet what ThingDescription will become once. At the moment it is typed as USVString.

[mkovatsc]

When splitting, why not revert to consume() and consumeUri() ?
What was the reason to consolidate? I guess the parameter object passing felt like offering this...

[zolkis]

It was a lengthy discussion. The "pro" argument for splitting to fetch() and consume(): in web API design fetch is a well known procedure, it also has its standard. It outsources connection and security issues to another (possibly external) algorithm than the consume() algorithm.

The "con" arg would be that WoT fetch may be so different from the Fetch standard that the name would just create more confusion. This is a "social" hypothesis and needs to be checked before we base API decisions on it. But even if it's valid we could use fetchDescription() name which avoids confusion.

[danielpeintner]

I still think having a 2 step approach to consume a TD makes sense.

Step1 (optional), fetching a TD might involve protocol bindings based on an URL such as retrieving a TD from an http, coap, data, ...URL. This process might become rather complex also with regard to security.

Step2, actually consuming a TD based on a ThingDescription "object/representation" is straight forward. Step2 is required and does not restrict "where" the TD comes from...

[zolkis]

Addressed by #86.