- 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