11:59:49 RRSAgent has joined #wot 11:59:49 logging to http://www.w3.org/2016/11/07-wot-irc 12:02:22 present+ Kaz_Ashimura, Dave_Raggett, Kazuaki_Nimura, Uday_Davuluru 12:05:01 present+ Johannes_Hund 12:05:13 jhund has joined #wot 12:05:55 masato has joined #wot 12:06:17 present+ Zoltan_Kis, Frank_Reusch 12:06:31 present+ Yingying_Chen 12:06:37 present+ Johannes_Hund 12:06:39 uday has joined #wot 12:06:44 present+ Fent_Zhang 12:07:04 scribenick: dsr 12:07:08 s/Fent/Feng/ 12:07:14 scribe: Dave_Raggett 12:07:32 meeting: Web of things scripting task force 12:07:40 Chair: Johannes 12:08:33 https://github.com/zolkis/wot/blob/master/proposals/restructured-scripting-api/intel-proposal.md 12:10:14 zkis has joined #wot 12:11:30 Zoltan presents his scripting API proposal 12:12:26 He starts with discovery. He has updated the issues and is seeking feedback. 12:12:53 He had a version with observers, but these aren’t ready yet 12:13:16 The existing proposal uses a promise and returns an array 12:13:57 You can’t normally wait until the array is fully populated and instead need a mechanism that reports things as they are discovered 12:14:15 This suggests a call back/eventing mechanism 12:15:33 Johannes: we discussed some ideas for this, e.g. something like observers 12:16:24 Zoltan: observers are a design pattern for a series of notifications from ECMA TC39 12:16:43 … for JavaScript 12:17:49 For now we can stick with an exising solution, and plan to support JavaScript observers once they are widely supported 12:18:17 s/exising/existing/ 12:18:58 Johannes: we could use something like setInterval so that you can cancel the notifications 12:19:38 q+ 12:20:19 We would need a means to inititate and to cancel the notifications for discovery 12:21:54 Dave: why not use regular events with filters and live arrays as in Mac OS? 12:22:10 Zoltan: we can’t use filters with events. 12:23:29 Dave: why not? We are free to define the API for subscribing to events. We could define a filter as static data, or as a call back. 12:23:47 Zoltan: I am not against it if we can do it 12:24:04 q+ 12:24:08 ack d 12:24:24 Dave: anyone prepared to comment on live arrays? 12:24:41 Johannes: it is a bit abstract and I would like to see an example 12:25:16 ack kaz 12:25:20 Dave: it is used by Apple for zeroconf with mDNS 12:25:54 Kaz: the W3C Multimodal Interaction WG have been working on discovery, and I would like to invite their suggestions 12:25:59 Johannes: okay 12:26:38 Johannes: perhaps Dave could provide further details in email 12:26:44 k_nimura has joined #wot 12:27:13 present+ Masato_Ohura 12:27:18 Zoltan moves on to discuss his consumerThing API 12:27:31 s/consumerThing/consumedThing/ 12:28:38 This has several operations inspired by REST 12:28:51 q+ 12:29:36 (presumably consumed thing is the API for a client of a thing) 12:30:34 ExposedThing is the corresponding API for scripts that are publishing a thing. 12:32:20 Zoltan walks us through the register and unregister operations 12:33:13 Both the consumed and exposed thing APIs are compatible with REST protocols 12:33:25 ack jhu 12:33:25 q? 12:33:41 rrsagent, set logs public 12:34:25 Johannes: so far we have things with properties, actions and events. I am unsure how your proposal maps to that model? 12:34:54 Zoltan: my proposal maps to the whole thing 12:35:21 Johannes: so you could use a PATCH operation to update properties? 12:35:24 Zoltan: yes 12:36:11 Johannes: your proposal is similar to what we have already discussed, but is somewhat lower level, e.g. with CRUDN operations 12:36:59 Zoltan: … how do you have a tree of things … 12:37:35 Johannes: consider how to set an observer for a single property, how would you support that? 12:37:58 Zoltan: an ECMAScript observer 12:38:33 Johannes: Dave talks about proxy chains 12:39:06 q+ 12:39:21 We should discuss the different approaches and where it makes sense to combine them 12:39:23 q? 12:39:32 Zoltan: yes, for that we need the use cases 12:39:34 ack k_nimura 12:40:17 k_nimura: we need to separate the client and server APIs 12:40:49 … especially for a tree of proxies 12:41:25 Zoltan: we do allow for that (explanation missed) 12:42:19 Johannes: it could be that constrained nodes only support a subset of the APIs 12:42:45 One example, is the means to add properties dynamically at run time 12:43:02 s/(explanation missed)/having both the client APIs and the server APIs/ 12:43:12 We may want a means to check what capabilities a given server supports. 12:43:57 k_nimura: we need rich capabilities for the cloud 12:44:20 Zoltan: we could have an API for when the model changes 12:44:39 present+ Kevin_Jordan 12:45:16 Johannes: I am working on a demo for this with dynamic things, e.g. adding and removing properties. I will provide a pointer when it is further along 12:45:43 Not every runtime needs to support the disovery API 12:45:57 rrsagent, draft minutes 12:45:57 I have made the request to generate http://www.w3.org/2016/11/07-wot-minutes.html kaz 12:46:03 q+ 12:46:11 Zoltan: each thing would provide access to what capabilties it supports 12:46:27 In OCF these are referred to as “interfaces” 12:47:09 q+ 12:47:19 Zoltan: this is also related to access control. However, I am not sure how general it is across different protocols 12:47:30 ack k_nimura 12:47:50 k_nimura: is there a lifecycle document available from the OCF? 12:48:49 Zoltan: the interfaces are defined statically in advance 12:49:14 q+ 12:49:33 k_nimura: if you think about tree structure, you may want to consider a dynamic API, but it isn’t there in OCF right now? 12:49:41 Zoltan: no it is not 12:49:43 ack kaz 12:50:39 Kaz: so we plan to consider adding a capabilties mechanism to the current practices? 12:51:15 what are the next steps? 12:52:22 Johannes: my view is that we have an overlap with what OCF is doing, however, we also see differences, I think we should review the use cases and then decide how to proceed in respect to the next plugfest 12:52:36 s/a capabilities mechanism/some more mechanism, e.g., server capability,/ 12:52:57 s/practices/practices based on today's discussion/ 12:53:28 We only have a few months before the next plugfest, so we need to progress quickly 12:53:43 but note that it is very open to comments 12:54:24 Zoltan: the web of things emphasises data models, and that is not so much the case for the OCF APIs, but we should look at the use cases 12:55:00 we don’t know enough to converge on the scriptin APIs right now 12:55:39 k_nimura: if we want to merge the specs, is the intention to automatically support OCF devices? 12:56:15 Zoltan provides some further background 12:56:50 Zoltan: e.g. in the context of dynamic models, that should be worked out at W3C 12:57:16 Johannes: are there any implementations we can look at? 12:57:36 Zoltan: Michael Koster has one based upon the OCF REST server 12:58:20 Johannes: so we need to consider the use cases over the next month to drive the discussion along with appropriate examples 12:58:41 olivexu has joined #wot 12:58:45 It would be good to include some OCF devices in the plugfest 12:59:14 Zoltan: that would be a good idea 12:59:39 Johannes brings the meeting to a close and thanks Zoltan for his contributions 13:00:09 Zoltan will update his proposal and provide a pull request 13:00:50 Johannes: lets look forward to discussion on combining APIs. 13:01:14 Others are invited to also put together some proposals fo future calls. 13:01:22 .., end of meeting … 13:01:29 rrsagent, make minutes 13:01:29 I have made the request to generate http://www.w3.org/2016/11/07-wot-minutes.html dsr 13:12:45 olivexu_ has joined #wot 15:01:14 Zakim has left #wot 15:15:26 dsr has joined #wot 16:30:29 thor has joined #wot