- From: Bassbouss, Louay <louay.bassbouss@fokus.fraunhofer.de>
- Date: Thu, 8 Oct 2015 13:45:06 +0000
- To: Kazuyuki Ashimura <ashimura@w3.org>, Public Web of Things IG <public-wot-ig@w3.org>
- Message-ID: <3958197A5E3C084AB60E2718FE0723D48E2F0008@FEYNMAN.fokus.fraunhofer.de>
Dear all,
Please find attached Mockups for a use case addressing the usage of the Thing API proposal.
Regards,
Louay
From: Kazuyuki Ashimura [mailto:ashimura@w3.org]
Sent: Mittwoch, 7. Oktober 2015 18:55
To: Public Web of Things IG <public-wot-ig@w3.org>
Subject: [TF-AP] minutes - 7 Oct. 2015
available at:
http://www.w3.org/2015/10/07-wot-ap-minutes.html
also as text below.
Thanks a lot for taking notes, Francois!
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
APIs and Protocols Task Force
07 Oct 2015
[2]Agenda
[2] https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0007.html
See also: [3]IRC log
[3] http://www.w3.org/2015/10/07-wot-ap-irc
Attendees
Present
Dave_Raggett, Kaz_Ashimura, Louay_Bassbouss,
Takuki_Kamiya, Yingying_Chen, Francois_Daoust,
Daniel_Peintner, Johannes_Hund, Claes_Nilsson,
Joerg_Heuer, Kazuaki_Nimura, Ari_Keranen, Arne_Broering,
Darko_Anicic, Michael_Koster
Regrets
Chair
Johannes
Scribe
tidoust
Contents
* [4]Topics
1. [5]Plugfest preparation & pre-hackathon on TPAC
2. [6]Technology landscape
3. [7]Scripting API for WoT model
4. [8]On-going deliverables of the Task Force
* [9]Summary of Action Items
__________________________________________________________
<scribe> scribe: tidoust
Johannes: [going through agenda]
... I note Claes request by mail on documents under
development. Other additions?
... [none heard]
Plugfest preparation & pre-hackathon on TPAC
<kaz> [10]Plugfest wiki
[10] https://www.w3.org/WoT/IG/wiki/F2F_meeting_29-30_October_2015,_Sapporo,_Japan#Plugfest
Johannes: I think that we have the requirements for the demo,
is that correct?
Kaz: Basically, the setting should be ok.
... The demo lists the demonstrations that will be made on the
first floor.
Johannes: We could do a hackathon to prepare the plugfest. Some
exchanges about rooms.
Kaz: The room next to the main demo hall will be available.
That is a room for storage and to keep devices.
... The meeting planning team suggested to use that room during
the day and in the evening.
... Maybe we can start the preparation at around 3PM.
... The network will not be available on Sunday though.
... Same thing for the AC supply.
... Of course we could bring our devices to the room, but
Sunday will not be a good time.
Daniel: Last time we discussed, there was the question of
Internet connectivity.
Kaz: For the plugfest within the meeting room?
Daniel: Yes.
Kaz: We could use wired connections and routers to create wifi
networks if needed.
... If we can clarify needs, we can talk to the systems team.
Daniel: And we need to decide who is going to carry around a
router.
Kaz: Another question is whether we need Internet connection
for the external network.
Johannes: I think we added a column to the table. Soumya does
not need connectivity apparently. Let's ask others to fill the
column as well.
Kaz: Jonathan filled out that table, need to check with him.
Daniel: Also, if there are too many devices around for
discovery, that may be a problem.
Kaz: Right, small local network should solve that.
Johannes: Takeaway is that we could use that storage room with
no time bounding. We need to decide whether it's Tuesday or
Wednesday.
... Which would be better, Tuesday or Wednesday?
Kazuaki: I can do both.
Louay: Also available on both days.
Johannes: Others are not on the call. For Siemens, both days
are possible as well.
Kaz: in that case, I suggest to try Tuesday first. If that
fails, we have Wednesday as a backup :)
Johannes: Right.
... Any other issue on the topic?
Dave: The request for demos for monday evening. Is anyone
willing to provide a demo for the developer event?
... See mail I sent earlier on. Just a reminder here.
Technology landscape
<inserted> [11]Technology Landscape wiki
[11] https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Technology_Landscape
Johannes: We have different consortia that are using different
technologies. Several protocols from the ones we've identified.
If people who contributed to this landscape could also
cross-reference the other IoT efforts so that we know which
supports which model.
... We need some more depth for the technology landscape.
... We had some discussions on CoAP for instance. If we could
complete the Wiki, that would give us more food to make
recommendations.
... Do we have people who can contribute more to this?
<kaz> scribenick: kaz
johannes: coap section
... Dave and Claes?
<tidoust> scribenick: tidoust
Claes: Yes, I can write something down
... Do you want a separate page for that?
Johannes: No necessarily, sub-bullets would be fine.
... What would be very good would be to identify criteria that
could be applied to all these protocols, such as availability
for wide area networks.
... That would create a list of questions to answer for all
these protocols.
... We already discussed them for CoAP, but they probably apply
for WebRTC, MQTT, etc.
Claes: OK, I'll see what I can do.
Johannes: Same thing for OneM2M, it would be good to list what
protocols they are using.
Michael: I would be happy to add some stuff on IPSO and on
OneM2M as well.
Johannes: That would be great, yes!
... Criteria applied to all of these would be quite good.
Volunteers welcome!
... Regarding the tech landscape, I think it would be good to
detail the different stacks and protocols.
Dave: Do we have an entry for AllJoyn?
Johannes: Not yet. Do we know someone who is involved in that
effort?
Dave: No, but Qualcomm is involved in that organization, so we
could get in touch with their AC Rep.
<scribe> ACTION: Dave to ask Qualcomm about contributions to
Tech landscape about AllJoyn [recorded in
[12]http://www.w3.org/2015/10/07-wot-ap-minutes.html#action01]
<trackbot> Created ACTION-11 - Ask qualcomm about contributions
to tech landscape about alljoyn [on Dave Raggett - due
2015-10-14].
Michael: They have also something called data driven API, which
seems interesting to us.
Scripting API for WoT model
Johannes: I think that Louay has a proposal here.
Louay: [presenting slides on WebEx]
... Same presentation as I presented two weeks ago in the
Discovery call.
... Idea of an API for the browser to discover and access
things
... Some of the concepts are taken from my involvement in the
Presentation API.
... Working on a plug-in for Cordova
... The main idea is to define a JavaScript API that allows Web
pages to discover and interact with things. Main point is to
consider security and privacy by design.
... Second point is to abstract from the underlying protocol.
... The API could be implemented on top of different protocols.
... Mainly useful for things that are not registered with a
particular server, such as things using Bluetooth Low-Energy
... [Louay explains the Presentation API, scribe suggests to
look at minutes of Discovery call where this part was minuted
in more details]
-> [13]http://www.w3.org/2015/09/24-wot-di-minutes.html#item01
Minutes of Louay's Thing API presentation in Discovery call
[13] http://www.w3.org/2015/09/24-wot-di-minutes.html#item01
Louay: Focus of Presentation API is presentation of web
content. Audio/video content will be considered afterwards. We
have a Cordova plug-in implementing the Presentation API.
... Chrome, Firefox implementing the Presentation API right
now.
... The idea with the Thing API is to use the same concept,
because there are common features between the two cases.
... The first analogy is linked to the need to discover
displays/things. The second analogy is linked to the need to
have a communication channel.
... A "ThingRequest" constructor would take a filter object
that describes all things that are of interest for the app.
... When the app starts the API, the user agent discovers the
things that match the filter. The user selects one thing
(possibly more than one) in the list.
... When the web page gets access to a thing, it gets an ID
that it can use later on to access the thing again later on.
This is useful for usability, as starting otherwise would
always display a dialog to select a thing, whereas for things
you may want to give access for a longer period of time.
... Then the Web page gets a Thing instance, on which it can
read/write properties or call actions.
... The web application will be notified when things are no
longer available.
... We started to implement this as a Cordova plugin, here only
on top of HomeKit, so only available on iOS.
... This is one showcase we want to present at TPAC.
... The goal is also for the Cordova app to serve as WoT
Servient that offers a Websocket server or HTTP server to
enable access to the things from other clients.
... So it's not only an application but also a Service.
... This is the reason why we need to run the app in the
foreground on iOS.
... I received feedback from Francois and Dave.
... Dave's comments are centered on JSON-LD. I don't think they
apply to the API itself.
... Francois wondered whether selection of multiple things
would be useful (in the Presentation API, only one display may
be selected). I think that's a good idea for things. For the
API, instead of one Thing, the application would simply receive
an array of Things.
... Second comment was about how browsers may handle a large
number of things that they discover.
... I think the API is more applicable to
sensors/actuators/things that are not registered on the
network, for home automation. That's the main goal of this API.
... Last comment was about the dialog display being shown to
the user each time the thing is first accessed. The ID
mechanism that I described would give the app the rights to
access the thing later on without prompting the user again.
... The Generic Sensors API addresses sensors that are
available on the device where the browser is running. Here it's
more related to discovery new things and interacting with new
things.
... In the Generic Sensors API, there is no discovery. You can
directly check whether a sensor is available.
... Questions? Comments?
Johannes: Can we view the API in two parts, the native
selection box and the Thing API itself?
Louay: Yes.
Johannes: Then there is the ability to expose the discovered
Thing as WoT Servient. Is that part of the API?
Louay: The API addresses the first two parts. To offer the
thing to other applications, I will implement another layer.
This is really for the plugfest, not part of the API.
... All the information you need will be in the Thing
description file
Johannes: The reason for my question is that this would enable
Thing-to-Thing communication in a very unified way.
... This would provide a way to discover things, wrap them for
exposure, and expose them to other things.
Louay: Yes. You will need specific protocols for discovery and
controls, but exposing could use existing standards more
easily. The Thing API I propose is not a solution for all the
features discussed here.
... We need other parts for registering things. Not part of the
browser API, I think.
Johannes: OK, but you form a proxy for the thing.
... I wonder why the split between the two parts.
... Risk of fragmentation depending on protocols used.
Louay: Yes. That is a problem with the Presentation API as
well. From an application perspective, you would be able to use
the same API but may not end up with the same list of available
displays depending on protocols supported by the underlying web
browser.
Johannes: If you were to implement a thing such as a lamp. You
would have another API to expose a thing. Why not have only one
API.
Louay: I agree. This is a basic idea. If you can inject your
ideas to extend my proposal, I'd be happy to discuss that next
time.
Dave: Just a question about the style for accessing things. To
some extent, I think this should be language-independent. Also
the question of synchronicity as developers will be more
expecting synchronous properties for instance.
Louay: If I set a property and then call an action after
setting the property. If I don't wait for the property to be
set, how can I be sure the action takes place at the right
moment?
Dave: Well, you may not be the only one accessing the thing in
any case. There may be something behind the scene.
Louay: You propose something such as "thing.colorTemperature =
42"?
Dave: Right, for devs, I think it makes sense.
... One question is to what level we need to standardize this
API. We need to define a data model, sure. What else? Open
question.
Louay: We could use the event on Monday to get feedback from
developers for instance.
Dave: As an IG, we should explore different options, I think.
... I need we need to get practical implementation experience,
so congrats for this work. The plugfest is a nice experiment.
We need more of that to point out these issues.
Johannes: Would it be possible to upload the script examples in
your slides to the GitHub pages?
Louay: Yes, I will do it.
<kaz> scribenick: kaz
tidoust: tx for mentioning all my comments
... please note Generic Sensor API work handles similar topics
... could converge common APIs
... upcoming draft will be published soon
... TPAC would be a good opportunity to start discussion
louay: Generic Sensor API focuses on reading data
... while WoT APIs handle accessing actuators
tidoust: right
<tidoust> scribenick: tidoust
Kaz: Unfortunately, DAP will not have a meeting at TPAC, but
Tobie will be there.
... We can probably have some joint discussion on Tuesday or
Wednesday with him and other people from DAP.
<kaz> [14]ad-hoc meeting proposal (Tuesday)
[14] https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Generic_Sensor_API
<kaz> [15]Breakout proposal (Wednesday)
[15] https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Generic_Sensor_API
Joerg: Maybe we should have a short list of ad-hoc meetings to
the IG agenda. Already a couple planned.
<kaz> +1
Johannes: skipping tooling for today in the interest of time.
On-going deliverables of the Task Force
<kaz> [16]Claes's message
[16] https://lists.w3.org/Archives/Public/public-wot-ig/2015Oct/0011.html
Claes: I had a look at the documents referenced by the Wiki and
I wondered which of them are still being pursued.
... For instance, the Architecture Model, is that still
relevant?
Johannes: I would like to open that question for the group.
... [no comment heard]
... During the F2F meeting in Sunnyvale, we made an attempt to
bring different views for the Web of Things model and
architecture together.
... However, we did not reach consensus to draw this into one
picture.
... It's not very clear to me how we can move forward.
Michael: I would suggest that we list documents that have clear
group consensus and that we maintain.
... Not doable overnight, but that's a question I got as well
Dave: Right, by charter, we also need to publish reports that
represent consensus of the group.
... We need to make it clear what parts are work in progress
... I think it's a question for the group as a whole.
... Something that the Chair and TF leads could work on for
preparation for the F2F in Sapporo?
Joerg: The most pragmatic is to discuss this by email. Whether
the Wiki is fine, where we put parts which have consensus, etc.
Claes: That sounds good.
Dave: The different task forces are working in the right
direction, e.g. security
Johannes: Where do we have the reference? How can we ensure
that we have a good list of documents?
Dave: Maybe start from the group's home page with a list of
documents on the right.
... And same thing on the IG wiki.
Johannes: Problem is to assess the maturity of documents.
Claes: Wouldn't it be good if task leaders take a stab at it?
<kaz> scribenick: kaz
johannes: I'd get an action item for that
... to describe the status of the documents
claes: which document for us to contribute
johannes: could list the existing documents
... that would be feasible
kaz: we can add links to the existing documents to the "Work in
progress" section
... and the moderators can add brief description to each list
item
->
[17]https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Work_i
n_progress work in progress section
[17] https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Work_in_progress
johannes: ok
claes: ok
johannes: other TF managers should also do that
... and make the decision on which to be continued during TPAC
... have we addressed all your points, Claes?
claes: yes
johannes: tx
... we're getting out of time
... any other business?
(nothing :)
[ adjourned ]
Summary of Action Items
[NEW] ACTION: Dave to ask Qualcomm about contributions to Tech
landscape about AllJoyn [recorded in
[18]http://www.w3.org/2015/10/07-wot-ap-minutes.html#action01]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [19]scribe.perl version
1.140 ([20]CVS log)
$Date: 2015/10/07 16:52:05 $
[19] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[20] http://dev.w3.org/cvsweb/2002/scribe/
--
Kaz Ashimura, W3C Staff Contact for Auto, WoT, TV, MMI, Voice and Geo
Tel: +81 3 3516 2504
Attachments
- application/pdf attachment: thing-api-usecase-mockups.pdf
Received on Thursday, 8 October 2015 13:45:56 UTC