scribenick: kaz
Sebastian: Agenda for today
... Note on the W3C Patent Policy for guests
<kaz> Architecture: Taki
<kaz> node-wot tutorial: Kaz, Zoltan
<taki> scribeNick: taki
Lagally: I cannot join marketing
call today.
... I already made all inputs.
... I would like to wrap up Arch discussion today.
... We discussed use cases for templates and geolocation,
etc.
... There is a document that is a working draft such as device
lifecycle comparisons.
... also there is lifecycle diagram.
<mlagally> https://github.com/w3c/wot-architecture/blob/master/proposals/Device-lifecycle-comparisons.pdf
McCool: there is also lifecycle content from Oliver wrt OPC-UA etc.
Lagally: can you provide URL?
<McCool> also pres by Oliver Pfaff is relevant to lifecycle discussion:https://github.com/w3c/wot-security/blob/master/presentations/2020-03-16-Bootstrapping%20IoT%20Security%20-%20The%20IETF%20Anima%20and%20OPC-UA%20Recipes.pdf
Lagally: We would like to discuss
WoT profile.
... after that, roadmap and action items.
Lagally: We can discuss 30
minutes maximum.
... Motivation is WoT adoption. Some companies had concern
about interoperability.
... We have interoperability using limited features in
PlugFests.
... across different companies.
... so we would like to formalize the agreements.
... wrt. properties, actions, events, links and security.
... Profile will select meaningful WoT core profiles.
<McCool> McCool: good point that we need to define minimum security support, too...
Sebastian: I have a question about diagram. Do we select a subset of properties, actions, events?
Lagally: Subset means adding
additional constraints.
... resursive levels, for example.
... for interactions, we need to these additional constraints.
Subset means you cannot use this and that.
... you cannot use 6000 characters name for example.
Sebastian: It is about data model, it sounds like. It is more about data model issue.
Lagally: Data model is important.
<McCool> McCool: I think sebastian's comment is just about the figure, might want to change the top-level categories to something like interactions, names, data models, links, and security
<McCool> ... for example
Lagally: It is filling gap for
device developers.
... so they understand how/what to implement properties, events
better.
... Meaningful constraints on data model is important.
McCool: Different categories. Costraints on names, properties, etc.
<kaz> profile definition within the charter
Kaz: I suggest to remove this diagram itself from this slide for now. We should go back to charter first to discuss.
Lagally: I would not remove this diagram, but we should discuss, I agree.
McCool: Charter says "subset",
but it does not say how.
... diagram is about what we need to think about when we
subset.
Lagally: we have 5 building blocks in specs now.
<McCool> McCool: suggest replacing this diagram with a simple list of the things we need to subset; may be more than five
<McCool> ... this will map to sections in the profile spec, most likely
Lagally: This figure is just
illustrative of what we need to discuss.
... Goals. I am concerned about out-of-the box
interoperability.
... between devices.
... including onboarding. This is important.
McCool: Self-documenting TD should not be part of the list. It can be discussed as part of TD discussion.
Lagally: We need to discuss that, too.
<McCool> McCool: for now just mark as "needs discussion"
<inserted> (Kaz agrees with McCool and thinks the 4th point "self-documenting TD" should be discussed but separately from this discussion on profiles today.)
Sebastian: Out-of-the-box
interoperability is valid for TD template. TD template is
missing protocol binding and security. But it has other
metadata.
... So it enables simulation. It needs to be out-of-the-box
processable for templates.
Lagally: Templates have not been used in PlugFests. But I agree TDT needs to be useful itself.
McCool: TDT, we need to define use cases for out-of-the-box TDT.
Lagally: This list is about published spec.
<McCool> McCool: so I suggest we table the TDT discussion for now, and return to it once we have a complete definition of the various (and multiple...) use cases for them
Kaz: I agree with McCool. This slide is about goals. Some are related points. For example, self-documenting TDs can be discussed somewhere else, I think.
Lagally: OK. self-documenting TDs. Some people suggested this point before.
<Zakim> dape, you wanted to interoperability *highly* depends on domain
Daniel: We need to make sure we
are not to define a "single" profile.
... There can be profiles for domains.
... I expect there are domains each has different
requirements.
Lagally: Is it protocol domains?
Daniel: Even within protocols, I expect different need for profiles.
Lagally: We can discuss meaningful constraints. There are common practices. Implementation details are different.
McCool: Human-readability is a
use case. We can discuss use cases.
... Some say we should have one profile. We can discuss union
of all domain requirements.
... One can make further subset later, also.
... we should have a single loose profile that describes what a
consumer needs to support to cover all domains first.
Lagally: We can go that details
later.
... Next, conformance tesing.
... With profile, simplified device validator and compliance
testing can be defined.
... Device can be certified.
... Also, validation tool. We have Ege's playground for
now.
... Next, Implementation complexity.
<McCool> McCool: by "loose" I mean "generous", i.e. fairly large limits on things, assuming a relatively powerful consumer
Lagally: 65,000 characters on string, for example.
Sebastian: We can be more precise here. I agree with your aspects of Consumers. I also want to stress on Producer aspects. Producer needs to describe its protocols, etc.
<McCool> McCool: diff between producer and consumer, +1
<McCool> ... limits are mostly relevant to the consumer, since the producer can state limits on what it can accept in the TD already
Lagally: Consumer's problem is
also producer's problem.
... You cannot sell products, for example.
Sebastian: You need to think about future, as well. There are multiple usages.
McCool: Consumers are in general powerful. But we can list protocols that consumers can use.
Lagally: POST or PUT for updating property, we need to make clear.
Sebastian: It is clear in TD spec.
McCool: TD is open-ended now, it may be problem for consumers.
Lagally: 4 use cases so far.
... high level use cases.
... Consumer needs to know if a device can work in the consumer's place before buying.
<McCool> McCool: needs vs wants; we NEED to make things finitely implementable; we WANT to limit complexity
<McCool> ... maybe should use
<McCool> ... "need" in certain use cases, "want" in others...
<McCool> ... an example; slide actually says "want"
Lagally: developer wants TDs to
be as simple as simple so development work is efficient.
... As a developer, I want to validate whether a device is
compatible with a consumer.
... as a service provider, integration of devices from many
vendors using TDT.
Zoltan: certification process.
How are we going to make it for WoT interoperability?
... What's our position on certification?
Lagally: It should be discussed with wider group(s).
McCool: we can discuss ourselves first on how. On the other hand, we need to discuss W3C, etc.
Ege: Isn't W3C against conformance testing?
McCool: We can start with which
implementation implements which features, and posting
results.
... legal limitation, we need to discuss with W3C.
... ...
<McCool> McCool: profiles should at least make it possible to have conformance testing for interoperability
Kaz: We should clarify our purpose here.
... As you remember, we invited several people working on testing to our F2F during TPAC 2018 in Lyon.
... We might want to provide a framework for WoT testing purposes publicly like the Web Platform Tests repo
Kaz: We need to discuss our requirements first.
Lagally: We started to clarify
requirements.
... We need to continue this discussion in Arch calls.
<McCool> McCool: ... and use cases, and stakeholders...
Lagally shows profile requirements...
Lagally: We need to work further
on this requirements. Please read them first.
... Recap of status.
... We have a GitHub repo. Issues are already there. Strawman
proposal is available.
... Next step, consolidate requirements, review strawman,
implement issues.
... questions?
McCool: We can list specs, how peofiles may impact.
Sebastian: I want to clarify further what profiles are.
<McCool> McCool: suggest we deal with this when we build overall use cases; each should identify deliverables they impact... including profiles (but also discovery, TDs, security, etc)
Sebastian: We need to be clear on intention of profile.
Lagally: We discuss them in architecture call. I agree with the point.
Lagally is showing architecture process diagram.
Lagally: Use cases leads to gaps
and building blocks, which makes requirements.
... There is draft roadmaps.
... Use case in march. Shortlist in April with requirements. We
have document drafted in May.
... We discuss profile strawman in March. Gather use cases and
issues. In May we want to have FPWD.
... This is rough schedule, though it is ambitious.
... We have new issues in architecture repo.
<inserted> virtual+F2F Issues on use cases created during the Virtual F2F
Lagally: We created them during
this Virtual F2F.
... Please check the list.
Lagally is iterating Use case assignments...
<inserted> Issue 456
Lagally: Ege, are you OK?
Ege: It is more about descrbing sensor accuracy property in general. Not limited to geolocation.
Lagally: OK.
... DID stakeholder terminology.
Sebastian: McCool or Oliver?
McCool: I can take a look at it as an input.
<kaz> Issue 455
McCool: We need alignment there.
Lagally: Can Sebastian check with Oliver on this?
Sebastian: Please keep me in there as a reminder.
Lagally: TDT terminlogy. We need to discuss.
McCool: also use cases for TDT.
Lagally: We have a issue for that.
McCool: We need to capture use cases we discussed.
Lagally showing issue #458...
<kaz> Issue 458
Lagally: OK
Lagally edited #458...
Lagally: We have use cases
documents in GitHub.
... MEIG can help some of them.
... Now we have owners for all of the issues.
... It is important to describe those use cases.
... We need lots of discussion for architecture.
... We have split call morning and evening hours in
Europe.
... any other businesses?
Sebastian: Thank you for all the origanization of Architecture work. It is not an easy work.
<McCool> McCool: I will have to drop for a few minutes to reboot my machine and try to fix my audio
Lagally: Thank you. Talk to you next week!
<kaz> scribenick: kaz
[Before starting this session, Sebastian asks everybody if it's OK to record the session and everybody agreed. So Kaz has started to record the session. We need to confirm how to publish the recorded video.]
<Ege> https://docs.google.com/presentation/d/1svxKEwCVoI_b1uyw_1zDOinkcCazz5Xzb5I4g2dpRUQ/edit?usp=sharing
Ege: starts to share the slides
above
... node-wot as an Eclipse project
... why "node-wot"?
... would like to hide the details of implementation
... what we do?
... how to write device implementation?
... possible without node-wot
... choose a protocol
... HTTP, MQTT, CoAP
... that's a pain
... then choose a library/framework
... e.g., mosquitto, flask
... that's also painful
... then program the backend
... and you need to write a TD
... make sure no mistake for the backend
... again
... programs interact with WoT devices without node-wot
... coose a protocol, library/framework
... then programming
... even more complicated
... parse a TD, program the app logic
... then send correct requests
... be sure no mistakes there
<McCool> McCool: well... or the developer should read, which is a "documentation" use case we should capture, actually
<McCool> ... the implementation may not actually parse the TD, and I think this is reasonable, IF the TD will not change
Ege: hopefully you support the
protocol of all TDs
... then
... with node-wot
... just program the app logic
... could focus on your projects/apps
... what is node-wot?
<McCool> McCool: although... yeah, we might do minimal parsing to find the concrete URLs; may be more relevant to say dev reads the TDT, so maybe "documentation" is a TDT use case
Ege: open-source node.js
library
... under Eclipse THingweb project
Ege: designed for WoT
apps
... highly modular
... features
... protocols: HTTP, CoAP, MATT, Websockets, OPC-UA
... media types: application/json, text/plain, images
... WoT operation supports
... security: basic auth, bearer tokens, API key, PSK
... note that node-wot is not an end-to-end framework
... questions?
(none)
Ege: let's see some action!
... start with simplified concepts
... then go into more advanced uses
... installation
... node.js 10.13.0 or later
... 1. clone the repo
... 2. change into the directory
... 3. install dependencies
... 4. build the source code
... 5. link the packages to enable the wot-servient
command
... all public in npm
... let's use it!
... WoT Scripting API is good document for the API
description
... how to write a Thing implementation
... start with describing the interactions
... first write a TD
... script for that
... describe properties
... like temperature including type, description, observable,
readOnly and unit
... then actions
<McCool> McCool: in example, Celcius should be Celsius
Ege: then events
... e.g., for overheat
... looks like a TD but no form section
... then we have to program
<McCool> McCool: also, "temperature of the room" should be "set-point of the thermostat"
Ege: how to read the temperature
from the internal sensor
... dummy functions here
... getTepmerature, changeTemperature
... thing.setPropertyReadHandler
... thing.setActionHandler
... thing.setActionHandler
... for the events
... setInterval for 5 seconds
... if the curTemp is more than 45 then thing.emitEvent
... at the bottom
... thing.expose
... we didn't have any protocol information so far
... all of that is done within node-wot
<McCool> McCool: although we probably should include protocol information... under discussion
<Ege> https://gist.github.com/egekorkan/ddf2e03f40fb976d9d4b925fbbb9d381
Ege: full code available above
<McCool> McCool: I do want to note that we are missing a step in this tutorial
<McCool> McCool: thanks, kaz; good point for comments
<Zakim> dape, you wanted to client side in Website also
Daniel: if you want the client side, you don't need to use node-wot
McCool: missing one step
... configure the servient
... how to setup security, config file, etc.
... very important documentation needed
Ege: exactly
... would like to show something
... there is a slide for that purpose
McCool: great
Ege: would like to go into
configuration as well
... (shares his editor screen)
... myTemperatureThings.js
... properties, actions and events
... this is proposed as specified
... property handler like this here
... myTemperatureThing.js
... running the code
... would like to explain how it works
<McCool> McCool: example needs to be cleaned up a bit to update SetPoint, not Temperature
Ege: changeTemperature
... connected to the MQTT broker
<McCool> McCool: otherwise it is technically inaccurate; a theromstat has a temperature sensor and then a set point at which it *tries* to control the temperature to meet
<McCool> ... but these are two separate properties, logically
Ege: TemperatureController
... http://localhost:8080/TemperatureController
... the name of the thing at the title field here
... read the temperature value based on the request
... increment/decrement
... also subscribe overheated one
<McCool> McCool: maybe I'm being pedantic but I find not being careful about this in a "controller" a bit jarring
Ege: http://localhost:8080/TemperatureController/events/overheat
... (has trouble with screen share)
McCool: good starting point
... but need improvement
... would like to hear fro the user side
... any opinions?
Zoltan: you can provide some
security-related setting
... installation for node-wot
Ege: (back)
<McCool> McCool: good point, but we have to make sure we also cover and document things not in the Scripting API, for instance, setting up certs for private keys, which (intentionally, for security reasons) is done "outside" the scope of the Scripting API
<Ege_> https://gist.github.com/egekorkan/ddf2e03f40fb976d9d4b925fbbb9d381
Ege: code available above
... how to use wot-servient command?
... WoT object is unknown for node.js
... wot-servient command builds the necessary infrastructure
and creates the WoT object for our scripts to use
<McCool> McCool: not quite sure why we have wot-servient; why don't we just require a package and manage it with npm etc?
Ege: command line interface for
node-wot
... we can specify the information for "servient"
<McCool> McCool: would be nicer to follow normal practice here for node scripts, imo
Ege: staticAddress for the
servient
... sections for protocols: http, coap, mqtt
... then credentials
... specify them within a configuration file
... and then run wot-servient -f conf-file
... get help by wot-servient -h
<McCool> McCool: although I guess we do need to discuss how and when the configuration file is read and the execution scope for node-wot is set up; it seems that is one of the motivations for the current structure
Ege: you can use any browser or
REST client
... as long as they use the expected protocols
... but you can do this easier/faster with node-wot
... and the code would be protocol-independent
McCool: nodeRED also should be included as a possible REST client?
Ege: right
... (shows example again)
... slide 30
... TemperatureThingAddress
<McCool> McCool: in general, we should document node-gen and the use of nodeRED with a similar set of tutorials
Ege: actual interaction by WoT.consume
<McCool> McCool: and these tutorials should point to each other...
Ege: we can create a thing
interact with
... slide 31
... setInterval
... if curTemp is less than 20
... await temperatureThing.invokeAction("increment", 4)
... send a request
... slide 32
... specify what the event does
... temperatureThing.subscribeEvent
... in case of overheat
<Ege_> https://gist.github.com/egekorkan/dfd0f999c22396a997eb10994e11aed6
Ege: display error message on the
console
... how to write code to interact with a Thing above
... would like to share the code again
... myTemperatureThing.js
... WoT.produce here
... WoTHelpers.fetch
... create temperatureThing
... to expose the methods
... (run wot-servient command)
... if specify "-c" option, it invoke the client
... any questions?
Zoltan: from the code, we need to add
cancelRequest, etc.
... to avoid infinite loop
... no way to cancel the request
... possibly some optional value for timeout
... will raise an issue
Ege: any other questions?
Cristiano: node-wot script uses the option to break?
Ege: yes
McCool: because this is node.js
... btw, wondering about typescript
(audio issue)
<McCool> McCool: just wondering about typescript vs node proper
<McCool> ... not mentioned, seems you are just using node
<McCool> ... but is there a way I can use typescript instead?
<McCool> ... not critical to go into detail here, McCool: but would like to understand
<McCool> ... eventually
Ege: coming into how to use
typescript
... not runable by default
... advanced feature for node-wot
... the minimum you should do so far
<McCool> McCool: ok, so there is an option to do it, but you don't have to worry about it if you don't want to
Daniel: right
Ege: let's get more advanced
... how to use as an npm dependency
<McCool> McCool: ok, use as npm dependencies answers one of my earlier questions ;)
Ege: recommend you use npm
dependency for more complex ones
... project code via require statements
... download the required packages from npm
... and run
... npm install @node-wot/core
... npm install @node-wot/binding-coap (optional binding)
... example
... slide 37
... upper part with [[Servient =
require("@node-wot/core").Servient
<McCool> McCool: question: can you also specify the configuration file programmatically?
<McCool> ... as a js object?
Ege: and start the servient
... servient.start().then((WoT) => {
... all the configuration as you wish within the upper
side
... lower part same as before
... slide 38
... client side
... build servient properly
... start it
... and same as before
... slide 39
... advantages
... better version control for node-wot
... installing on more constrained devices
... install only what your project needs
... better compatibility
... self-contained
... possibility to use Typescript and Intellisense
<zkis> scribenick: zkis
Ege: node-wot enables building
bigger apps for WoT
... for instance, WADE, Shadow-Thing, WoT-Testbench, WAM (WoT
Application Manager)
... how to contribute: add new protocol bindings (e.g. MODBUS
over TCP)
... or XMPP
<McCool> McCool: would add under "things to contribute": security schemes
Ege: bugfixes are welcome
Zoltan: should we standardize servient-specific APIs
Ege: the danger is to expose the protocol side of things
McCool: we could add an appendix for node-wot
Cristiano: about Shadow-Thing
<McCool> McCool: would be very helpful imo for adoption to fully document the "reference implementation" (node-wot) in one place
Cristiano: we have a use case about this automatic reverse proxy
Ege: you give a TD as an input, consume it with node-wot or shadow-thing and then expose it (after changing it)
Cristiano: but I can not consume the thing behind a firewall
Ege: the IP address is not visible in the TD until port forwarding is not configured in the firewall - it could be handled in the firewall
Christian: node-wot welcomes new
protocol bindings, but people should prefer existing ones with
the help of a proper TD
... and then send that to wotify
... one should use the base protocols and define a good TD
<McCool> McCool: another example would be OCF, which uses CoAP but with some special header options, security settings, etc
Ege: right, we might have too many bindings that way
Christian: e.g. Fujitsu vs Oracle bindings
Jennifer: 2 quick questions, came
up during a pilot
... would be nice to have a tutorial on how to set it up on
production
McCool: also, how to set up in docker, for production use as well
Jennifer: then, slides are shared?
Ege: yes
<Ege_> https://docs.google.com/presentation/d/1svxKEwCVoI_b1uyw_1zDOinkcCazz5Xzb5I4g2dpRUQ/edit?usp=sharing
Kaz: save the pdf version in the repo
<McCool> McCool: but also how to run as a daemon, using systemd, upstart, pm2, etc.
<McCool> ... also there is also a way to set up a daemon using docker
Jennifer: what is the difference between wot servient and cli.js?
Ege: no difference
... it's like a shortcut
... for pros, suggest using as npm dependency
<McCool> McCool: this is an example of something that is trying to make things easier that ends up just being confusing...
Daniel: the wot-servient command might be indeed confusing with the optional things
<McCool> McCool: and wot-servient is also limited; might be better for some people to just start with the npm approach first
Sebastian: thanks Ege for the presentation
Kaz: suggest updating node-wot documentation based on this presentation
Ege: right, we could even have a tutorials folder with various recipes
<McCool> McCool: I'd like to see a written tutorial, not just a video
<McCool> ... with similar content
<McCool> ... but I also want to say this is very valuable material
Kaz: you can use the minutes as a basis for that documentation refactoring
<Philip> Philip: I have a question on the support for Bearer token
<Philip> Philip: is it fully supported and do we have any example on using Bearer token with WoT?
Ege: yes, it's fully
supported
... in the plugfest, Panasonic used them
<Philip> Philip: it would be helpful to have an example on that
<McCool> McCool: need to add documentation, an example, and a tutorial on how to set up bearer tokens (and other security schemes, once we implement them)
Jennifer: in general, more examples to cover security
Sebastian: adjourning the tutorial
session
... now we will have a break
... will have the marketing session later
Marketing call starts in one hour
[adjourned]
