- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Tue, 09 Jun 2020 16:28:48 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/06/01-wot-minutes.html
also as text below.
Thanks a lot for taking the minutes, Zoltan!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
WoT Scripting
01 Jun 2020
Attendees
Present
Kaz_Ashimura, Cristiano_Aguzzi, Tomoaki_Mizushima,
Zoltan_Kis, Michael_McCool
Regrets
Chair
Zoltan
Scribe
zkis
Contents
* [2]Topics
1. [3]Prev minutes
2. [4]PR
https://github.com/w3c/wot-scripting-api/pull/209
3. [5]should we extend consume() to accept a URL in
simple case?
* [6]Summary of Action Items
* [7]Summary of Resolutions
__________________________________________________________
<scribe> scribe:zkis
Prev minutes
<kaz> [8]May 25
[8] https://www.w3.org/2020/05/25-wot-minutes.html
Minutes approved
PR [9]https://github.com/w3c/wot-scripting-api/pull/209
[9] https://github.com/w3c/wot-scripting-api/pull/209
Zoltan: reviewing the PR
McCool: should add editor's note to specify how the spec will
be evolving later, wrt Protocol Bindings
Zoltan: question: should readMultiple fail is not possible with
a single network request?
McCool: yes
Cristiano: yes
Zoltan: some help will be needed on defining how to handle URI
variables
Cristiano: there is an RFC 6570
Zoltan: maybe if there is anything in the Fetch Standard
Cristiano: question about arrayBuffer()
... the function reads all the bytes
... does that include decoding?
Zoltan: same as with the Body mixin, just providing the bytes
... value() now fails early if it can tell it has no chance to
succeed
... should we allow implementations to duplicate the stream?
Cristiano: it would be overengineering
... we could leave it this was and change later if needed
Zoltan: on "check data schema", if there is an external
algorithm available, let's change
... on writing, if schema is a string and source is not, should
we use JSON serialization?
Cristiano: need to think about that
Zoltan: let's create an issue
Cristiano: yes and experiment
Zoltan: OK, this was it. Still waiting on Daniel's input.
... will add the editor's notes
should we extend consume() to accept a URL in simple case?
<kaz> [10]D. Full Web IDL
[10] https://www.w3.org/TR/wot-scripting-api/#idl-index
McCool: make sure it is clear it's a URL and not a string TD
... if it needs security info, the runtime needs to be
provisioned
Zoltan: right
Cristiano: currently if we use Fetch we are limiting to HTTP,
so we cannot use CoAP
... if we include URL then we could use other bindings
... so this is a welcome idea
McCool: actually packet size limitations might be an issue with
CoAP
... on short term it is likely that distributing TD's would be
HTTP based
Zoltan: that is great information
McCool: we will study distributing via CoAP
Zoltan: CoAP would work well with constrained devices that
don't have HTTP stack but have CoAP support
McCool: doubt we'll do distribution with CoAP, but with CoAPS
... CoAP over TCP could be a solution
... anyway, the Scripting API should be independent
Zoltan: will create an issue or revive old issue to discuss
this
[meeting adjourned]
Summary of Action Items
Summary of Resolutions
[End of minutes]
__________________________________________________________
Minutes manually created (not a transcript), formatted by
David Booth's [11]scribe.perl version ([12]CVS log)
$Date: 2020/06/04 21:20:43 $
[11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[12] http://dev.w3.org/cvsweb/2002/scribe/
Received on Tuesday, 9 June 2020 07:28:05 UTC