Re: Project Things by Mozilla and the Web Thing API

Dave,

I am very skeptical of the idea that Web applications will be implemented
in JavaScript, in the long term.

Or in any imperative language, for that matter. The current software design
practice hasn't changed much since the 1960s, and it will not scale to
produce the amount of applications the Web of Things will require.

I think it has to be seriously considered that future Web applications will
be declarative, e.g. domain-specific models running on generic platorms
that interact using a single uniform API.


Martynas
atomgraph.com

On Fri, Jul 14, 2017 at 6:12 PM, Dave Raggett <dsr@w3.org> wrote:

>
> On 13 Jul 2017, at 19:49, Benjamin Francis <bfrancis@mozilla.com> wrote:
>
> Hi Zoltan,
>
> On 13 July 2017 at 11:10, Kis, Zoltan <zoltan.kis@intel.com> wrote:
>
>>
>> I agree with the goal of making TDs more Web-developer friendly, with
>> core vocabulary and then extensions.
>>
>
> Great. To contribute to that discussion I've filed an issue on GitHub
> <https://github.com/w3c/wot-thing-description/issues/12> proposing
> "properties", "actions" and "events" members at the top level of the Thing
> Description.
>
>
> Note that I am writing this on a personal basis and not on behalf of the
> WoT IG/WG or W3C.
>
> There is current interest in work on both simple JSON and JSON-LD for
> serialising thing descriptions. I have proposed an algorithm for mapping
> simple JSON into Linked Data, thereby making it feasible to map to and from
> JSON-LD and any other serialisations that emerge. The data types and
> constraints are based upon a subset of JSON schema that is modelled as
> Linked Data. The subset is based upon a broad range of use cases including
> those covered by OCF, oneM2M, ECHONET, and Bluetooth.
>
> I am also working with Darko on linking interaction models to semantic
> models as a basis for discovery, composition of services and adaptations to
> variations across devices from different vendors. As an example, consider
> the scenario where you plug smart lights into sockets around your home, and
> make use of a smart service to discover them and dynamically configure how
> they can be controlled from physical switches in the home and from your
> smart phone etc. This involves a means for services to discover the devices
> based upon the kinds of capabilities they expose, along with a means to
> model the context (the rooms in the home, and the devices in each room).
> We’re looking for the atomic building blocks to enable such smart services.
>
> Note that much of this can be implemented at the application layer as
> virtual things that offer smart services, e.g. as agents that run on a home
> hub to register things and provide access to a repository of information
> about the things in the home along with the context. By implementing some
> proof of concept demos, we can validate the requirements for the core
> underlying standards. Additional complementary standards could be added
> later as market experience dictates, just as has happened for CSS for web
> browsers.
>
>
> Also, the gateway concept looks sound. However, I'd be interested in how
>> far can we go with protocol bindings. Packaged SW update is less of an
>> issue for a gateway, but it's probably more difficult for an end device
>> that needs re-flashing and it's already deployed.
>>
>
> I'm not sure I understand what you mean. What's the link between protocol
> bindings and over the air updates that you're making?
>
>
> Good security practices call for secure means to apply updates as defects
> are discovered. Furthermore, to connect a new device to a gateway may
> involve installing a driver for a new protocol or communications
> technology. Each driver will be controlled via the corresponding metadata
> in the thing description.  My proposal is to include an identifier as a URI
> that can be dereferenced to obtain metadata for the required driver, for
> instance, implementations appropriate to different IoT platforms, along
> with the security credentials needed to verify the integrity of the driver
> as it is installed.
>
> An IoT platform is likely to only need a few drivers to be installed in
> normal practice, for instance, Bluetooth, OCF, oneM2M, generic drivers for
> HTTPS and COAP, and for Web Sockets and Server-Sent Events.
>
>
>
>> Scripting is an optional building block for WoT, and IMHO it's not in
>> conflict with your goals about web interfaces and SW libraries. You could
>> consider it as an example, rather than _the_ way to do Things.
>>
>
> I agree that it isn't in conflict, but if it's not intended to become a
> W3C recommendation of _the_ way to do Things then why does it need to be a
> W3C specification at all? Why not just implement pieces of software as
> demonstrators of how a scripting runtime could be created to talk to web
> things.
>
> Implementations may differ, but the use cases and context stay the same. Therefore,
>> IMHO it still makes sense to standardize a WoT Scripting API for
>> JavaScript/TypeScript. They do work against a web interface (the WoT
>> interface).
>>
>
> It's interesting that you describe it as standardizing a scripting API for
> JavaScript/TypeScript, because the charter
> <https://www.w3.org/2016/12/wot-wg-2016.html> makes no mention of those
> languages and actually says "APIs will be defined in ways that are
> independent of the choice of programming languages". This is one of the
> points I felt was unrealistic.
>
> To be honest I still don't understand what the Scripting API actually is
> or what it has to do with the web. The web is made of resources linked by
> URLs, not function calls. All the terminology around runtimes and
> life-cycles reminds me a lot of the packaged app runtime
> <https://www.w3.org/TR/runtime/> the System Applications Working Group
> tried to create which also had nothing to do with the web and went nowhere.
>
>
> The key deliverable for the WoT IG is the work on thing descriptions. The
> scripting APIs can be seen as good design patterns that will make it easier
> for developers to switch from one platform to another.
>
> The idea of a manager thing is that we can re-use the core standard for
> thing descriptions and APIs rather than having to invent something
> completely new. This includes the means to (un) install applications, to
> (un) register applications, to securely update them and so forth.
>
>
>
> Who would implement a standard JavaScript/TypeScript API?
>
>    - Browsers vendors? Have any browser vendors expressed an interest in
>    this? Why can't web applications reference web things using URLs like any
>    other web resource and communicate with them over HTTP & WebSockets using
>    the DOM APIs that already exist?
>    - Server-side JavaScript implementations? Why can't web servers serve
>    Web Thing descriptions like any other web resource and host REST &
>    WebSocket APIs to communicate with them like any other web service? If HTTP
>    or HTTP/2 aren't fit for purpose for IoT use cases for some reason then
>    let's talk to the IETF and create an HTTP/3.
>
>
>
>> Also, it makes sense to work on and have examples on script deployment
>> (Manager Thing), related use cases, functionality, vocabulary etc
>>
>
> What is "script deployment"? What is a "manager thing"? I can't find these
> concepts defined anywhere.
>
> Similarly, the WoT interface concepts can be applied to access to system
>> specific functionality. TD's can be defined for a wide range of
>> functionality.
>>
>> Security, privacy, access rights, policies, "manifests" (SW extensions),
>> etc are work in progress where Mozilla's input would be beneficial.
>>
>
> I'm happy to try to get Mozilla input on any open issues. I'm not sure
> what you mean by "manifests (SW extensions)" though.
>
> I'm sorry for all the basic questions but I'm still struggling to get my
> head around the vision of the Web of Things described in the current
> working group charter and the documents currently being produced. As a web
> developer it doesn't sound like anything I recognise as the web.
>
>
> The fragmentation of the IoT is widely recognised as a problem.  However,
> the variation in requirements across use cases and application domains make
> it very unlikely that a single approach will win out.  We’re therefore
> trying to standardise a basis for describing things as a basis for
> decoupling apps from the underlying protocols and communication patterns.
> These descriptions form a Web of things, analogous to the existing Web of
> pages supported by Web browsers. Thing descriptions may include references
> to other things, e.g. where one thing depends on the services provided by
> other things.
>
> Web pages are executed by Web browsers. Applications for the Web of things
> are executed by application platforms that map the thing descriptions into
> objects that forms part of the application execution space. Application
> platforms may support multiple protocols, e.g. HTTP for Web pages and
> access to thing descriptions, and CoAP and Web Sockets for messaging. Web
> developers will be able to use familiar technologies such as JSON for
> descriptions, and JavaScript for programming, but we want to avoid the need
> for a developer to have to master the details of myriad different IoT
> standards, for which the effort can be delegated to IoT driver developers.
>
>
> Ben
>
>
> Dave Raggett <dsr@w3.org> http://www.w3.org/People/Raggett
> W3C champion for the Web of things
>
>
>
>
>

Received on Saturday, 15 July 2017 12:13:59 UTC