[Redesign] Possible Thingweb Component Combinations

[egekorkan]

As discussed in today's call, we can think of useful Thingweb component combinations in different scopes. I will write some below but everyone can write some other ones. We do not need to limit to Thingweb components but no need to promote other stuff more than our components. Most WoT applications have a subset of the following parts, for which we have some components already:

1. Thing Program: HW interfacing, protocol stack, logic

• node-wot
• Node-RED blocks (built with node-wot)
• dart_wot (soon)
• Online Things (not a component though)
• Any WoT device

2. Consumer Program: Logic, UI, Protocol stack

• node-wot
• Node-RED blocks (built with node-wot)
• dart_wot

3. TD-based tooling (validation, TD transformation etc.)

• td-tools
• playground

4. TD Directory

• Domus TDD

Basically, anything from categories 1 and 2 can be combined. They can be enhanced by tools from td-tools or Domus TDD. With tools from td-tools, we can integrate into or from other ecosystems such as AAS, OpenAPI or AsyncAPI.

Concrete combinations are coming soon as edits to this comment.

[egekorkan]

Simple Consumer-only workflow

1. I get a device from a manufacturer without TD/TM. I write a TD/TM (or is given by the manufacturer). I validate it with Playground. I write the Consumer application with node-wot. Highlight: It can run on the browser.
2. Same as above but the Consumer application is in dart_wot. Highlight: It can run on mobile
3. Same as above but the Consumer application is with Node RED components of node-wot. Highlight: Easy to program with visual building blocks.

• Here, the Things can be our online things so that people have the least barrier to entry. In that case, no validation is even needed.
• This is the case where we have a device like SentronPAC from Siemens and need to integrate it into a system thanks to TD.

Simple and homogenous workflows

1. node-wot Thing, node-wot Consumer: I write node-wot code and deploy it on a RPi, attach some sensors and interface to them. It generates the TD and I know exactly where it is (no need for discovery) and it is valid (no need for playground). I write the Consumer application.
2. Node-RED Thing, Node-RED Consumer: Same as above.
3. dart_wot Thing, dart_wot Consumer: Same as above.

• Here, Thing and Consumer component can be made heterogenous (node-wot Thing, dart_wot Consumer).
• This is a more advanced workflow, a bit more DIY since you are building a device. However, attracting more DIY community reps are good since there is more open-source collaboration possibilities.

Professional workflow

1. Multiple people are building Things or have built them. Each has used another framework, programming language and protocol. They also have their TDs
2. They validate their TDs on Playground.
3. They submit their TDs to an instance of Domus TDD (of their organization)
4. Other people search and find the relevant TDs. They start writing Consumer applications (any of the above components)

• Here, we try to highlight the scaling effect. Even there, Thingweb is on your side!

Maybe as a generic message, starting somewhere (others' device or your own DIY device) but scaling thanks to Thingweb is a nice idea.