- From: Vlad Trifa <vlad@evrythng.com>
- Date: Tue, 19 May 2015 17:32:58 +0100
- To: Dave Raggett <dsr@w3.org>
- Cc: "Heuer, Joerg" <Joerg.Heuer@siemens.com>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
- Message-Id: <ADFA36C1-546C-495E-B3CF-98AC3BE6E68C@evrythng.com>
> The Web of Things goes well with the Internet of Things (one is built on the other) and both terms are well established. Well, indeed... that's why I proposed to call a Web Thing any "thing" (physical or virtual) that is part of the Web of Things. In other words, as long as I can access data/service of a Thing over the Web (from my browser, an app on my phone, or more generally any HTTP client I'm writing) - then it is a Web Thing. My personal website isn't a Web Thing. But if I extend the server it's hosted on so it can proxy other "Things" (and expose the payloads/models/formats we're trying to define), then it becomes a Web Thing, do you agree? HTTP first is because of the layered architecture of the Web. Where the "Web-enablement" happens (the HTTP server my Javascript app needs to send a request to in order to unlock my garage door) is transparent from a Web Thing Client perspective, so you could embedded an HTTP server directly on the device if you *really* want to, or simply on an intermediate server in the cloud which "hides the fact that it's actually talking with something else to device, like MQTT" - it just doesn't matter! I'll still be writing my app using high-level "Web" concepts (the WoT language we're trying to define)! The point we're trying to make is that we propose HTTP, because it's what most "Web of Things developers" will use to build WoT apps. If I had to learn MQTT, CoAP, XMPP, plus a few more, to build IoT client apps (which is the case today), then we wouldn't need this working group in the first place. This is the major problem we're trying to solve I believe, no? More importantly, there's no point arguing whether we need CoAP, MQTT, and co: it's clear that we need them!!! But if I'm a front-end developer and can write a simple app only using HTTP, to control a bunch of physical devices (that might be connected using MQTT, COAP, or anything else) then that'd be sweet! And I don't even need to know which device speaks what because these are "encapsulated" behind Web Things (proxies that map them) and all I need to learn is the Web Things "standard"! And if that's the outcome of this work group, then I'll proudly say we've been successful! So, in short, I believe we're talking about the same thing and share the same vision, so we simply need to agree on a set of basic concepts that we can all take for granted and build upon. Does this all make sense? Anyone sharing these thoughts? Or disagreeing? > My web page web of things library for browsers is currently limited to proxying things hosted on servers, but in principle, it could be extended to support peer to peer connections with other browsers via WebRTC, or even indirectly via a web of things server, although I am not sure of the use cases for this right now. > > Thanks for sharing your proposal. It seems to be limited to HTTP and moreover doesn’t seem to cover the PATCH method which is handy for REST when you only want to change a small part of the state. Constrained devices may want to use CoAP or MQTT. Pub-sub protocols like XMPP and MQTT are convenient when you have an unlimited number of clients/proxies for a given thing. I wonder why you limit things to the physical world? > > Cheers, > Dave > >> On 19 May 2015, at 13:44, Vlad Trifa <vlad@evrythng.com <mailto:vlad@evrythng.com>> wrote: >> >> Thanks! >> >> How about simply "Web Thing"? Because the Web of Things is made of Things - Web Things. It seems simple enough to be useful & reusable. >> >> A Web Thing should automatically imply that it's a server, otherwise it's not accessible over the Web. >> >> What might be a useful term though is "Web Thing Client" or "Web of Things Client", which means it can access, read, and control other Web Things, but doesn't expose its services on the Web. >> >> This is what we've proposed in our proposal here: bit.ly/wot-label <http://bit.ly/wot-label> --> feedback very welcome! >> >> Thoughts? >> >> Vlad >> >> >> -- >> vlad trifa, phd //// >> co-founder, head of r&d + innovation >> m +44 750 888 2051 // w evrythng.com <http://evrythng.net/> >> t @vladounet /////// w vladtrifa.com <http://vladtrifa.com/> >>> On 19 May 2015, at 11:52, Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> wrote: >>> >>> >>>> On 18 May 2015, at 19:42, Heuer, Joerg <Joerg.Heuer@siemens.com <mailto:Joerg.Heuer@siemens.com>> wrote: >>>> >>>> So I did the exercise to draft some architecture aspects from my view point and share >>>> >>>> a) the attached slides showing those aspects (I assume they are not self explanatory yet, but for sure you have some associations ;-) and >>>> b) the plantUML source code, so you can edit or augment the figures e.g. with an online editor e.g. [PlantText] >>>> >>>> In the webconf tomorrow I can give a brief introduction to the slides, but even more important we need to discuss if we can agree to take plantUML for joint editing of these views and understanding. It is my understanding that in parallel Johannes is conducting some experiments to integrate plantUML figure generation into github so we not have to share two documents as done for illustration above but can work on a single one. >>>> >>>> So please share your ideas on this. >>> >>> Thanks for sharing this with us. Any particular reason why the term “wot servient” has been introduced here? For me, Web of Things Server is clearer — it is a web server that hosts things. >>> >>> My implementation work, and my look at microcontrollers suggests that a critical part of the architecture will be the metadata and the need to cleanly separate descriptions of things, security and communications related aspects. One example is to cover the possibility that some servers will batch data and even multiplex data from different sensors. >>> >>> Best regards, >>> >>> — >>> Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> >>> >>> >>> >> > > — > Dave Raggett <dsr@w3.org <mailto:dsr@w3.org>> > > >
Received on Thursday, 21 May 2015 07:54:40 UTC