w3c / w3c/wot-scripting-api

Yet another subscription API

Open
#268 9 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

API-improvement enhancement
Dominant language
HTML
Stars
45
Forks
21
PR merge metrics
No merged PRs in 30d

Description

As requested here I wrote a new IDL for yet another variant of the subscription API. Please see the following Web IDL:

[Exposed=Window]
interface ConsumedThing {
  /*... other methods */
  ObservationHandle createObservation(DOMString name, optional InteractionOptions options = null);
  SubscriptionHandle createSubscription(DOMString name, optional InteractionOptions options = null);
};


[Exposed=Window]
interface AffordanceHandle : EventTarget {
     attribute EventHandler onerror;
};

[Exposed=Window]
interface SubscriptionHandle : AffordanceHandle {
     undefined subscribeEvent();
     undefined unsubscribeEvent();
     attribute EventHandler onunsubscribeevent;
     attribute EventHandler onevent;
     attribute EventHandler onsubscribeevent;
};

[Exposed=Window]
interface ObservationHandle : AffordanceHandle {
     undefined observeProperty();
     undefined unobserveProperty();
     attribute EventHandler onpropertychange;
     attribute EventHandler onobserveproperty;
     attribute EventHandler onunobserveproperty;
};

The design idea is to re-use as much as we can what is already out there. Therefore, here we are using EventTarget and EventHandler.

Pros

  • Compliant to [Web Platform Design Principles]https://w3ctag.github.io/design-principles/#dont-invent-event-like
  • no callback - promise duality
  • In the future, we could adapt this pattern also for actions. For example, if we find a way to define long-standing actions in the TD, we could define an ActionHandle
  • It still evokes TD basic operation verbs (i.e. observeProperty, onevent)

Cons

  • More verbose
  • Harder error handling for subscribe, unsubscribe, observe, and unobserve (i.e. you can't try {}catch{} but you have to use the EventHandler

What do you think? 🤔

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the linked pull request and its referenced discussion, then compare this proposed Web IDL with the subscription API already described in the project. The issue identifies no implementation files or tests; done would require an agreed API design and the corresponding project changes.

Written by the indexing model from the issue text.

Assessment

Domain
api, web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.