Open zolkis opened 1 month ago
The current API (collated the partial definitions):
typedef object ThingDescription;
typedef object ExposedThingInit;
[SecureContext, Exposed=(Window,Worker)]
namespace WOT {
Promise<ConsumedThing> consume(ThingDescription td);
Promise<ExposedThing> produce(ExposedThingInit init);
Promise<ThingDiscoveryProcess> discover(optional ThingFilter filter = {});
Promise<ThingDiscoveryProcess> exploreDirectory(USVString url,
optional ThingFilter filter = {});
Promise<ThingDescription> requestThingDescription(USVString url);
};
[SecureContext, Exposed=(Window,Worker)]
interface ThingDiscoveryProcess {
constructor(optional ThingFilter filter = {});
readonly attribute boolean done;
readonly attribute Error? error;
undefined stop();
async iterable<ThingDescription>;
};
dictionary ThingFilter {
object? fragment;
};
I propose another top level API to obtain the WoT object, given configuration.
[SecureContext, Exposed=(Window,Worker)]
namespace WOT { // separate conformance class
Promise<WoT> createWotEndpoint(optional WotEndpointInit init);
Promise<void> decommissionWotEndpoint(WoT wot);
Promise<void> provision(WoT wot, WotProvisioningInit init); // (re)provision
Promise<void> configure(WoT wot, WotConfigurationInit init); // (re)configure
Promise<void> initDiscovery(WoT wot, WoTDiscoveryInit init); // (re)init discovery
Promise<void> addDiscoveryDirectory(WoT wot, USVString url);
// add other methods operating on WoT
}
[SecureContext, Exposed=(Window,Worker)]
interface WoT {
Promise<ConsumedThing> consume(ThingDescription td);
Promise<ExposedThing> produce(ExposedThingInit init);
Promise<ThingDiscoveryProcess> discover(optional ThingFilter filter = {});
Promise<ThingDescription> requestThingDescription(USVString url);
// internal slots will include the entities configured in WOT,
// e.g. provisioning object, discovery object, configuration object etc
}
We could discuss whether the WoT.discover()
method should just provide Thing TDs, based on directories and other discovery methods configured for the WoT
object in the WOT
namespace.
Alternative names for WoT
could be WotContext
, WotEndpoint
etc, basically the same as the current WOT namespace, just made an interface object. It could also be constructible (with defaults) and (re)initialized later. Like this.
[SecureContext, Exposed=(Window,Worker)]
namespace WOT { // separate conformance class
Promise<void> provision(WoT wot, WotProvisioningInit init); // (re)provision
Promise<void> configure(WoT wot, WotConfigurationInit init); // (re)configure
Promise<void> initDiscovery(WoT wot, WoTDiscoveryInit init); // (re)init discovery
Promise<void> addDiscoveryDirectory(WoT wot, USVString url);
// add other methods operating on WoT objects
}
[SecureContext, Exposed=(Window,Worker)]
interface WoT {
constructor();
Promise<ConsumedThing> consume(ThingDescription td);
Promise<ExposedThing> produce(ExposedThingInit init);
Promise<ThingDiscoveryProcess> discover(optional ThingFilter filter = {});
Promise<ThingDescription> requestThingDescription(USVString url);
// internal slots will include the entities configured in WOT,
// e.g. provisioning object, discovery object, configuration object etc
}
It would be possible to experiment with moving directory exploration (back) to WoT, but this is a good starting point.
The discussion in #535 is relevant to this issue.
I think that it is great to start talking about a broader scope of the scripting API. One question: is this discussion also framed inside https://github.com/w3c/wot-scripting-api/issues/298 ? I know that this proposal is concerning only Discovery but I see how that could be extended also to other aspects like security schemas, protocol bindings, and security data.
@relu91 I think script management is a different topic. This one only addresses configuration/provisioning (including that of discovery) and kind of assumes that it's done for a(ny) single given script run in the environment.
Managing multiple scripts is a different API from this point of view, which in background might (or might not) spawn a new instance of the runtime, depending on policy of co-hosting or isolation. That part will also need its own provisioning, i.e. will need to include also data that may be relevant to script management, as an incremental feature (additional provisioning and config items related to script management).
Based on the comment in https://github.com/w3c/wot-scripting-api/issues/545#issuecomment-2220314305, this issue discusses a proposal to handle multi-solution support, provisioning and discovery mechanisms.