Method for supporting devices without requiring a HTTP server for the device.

[Faeranne]

Thermostats and TV's are mentioned as examples of potential connected devices, but with things like lights and other low power devices, providing a full HTTP server that can pass a web page could potentially require more resources than are viable for the device.

It would make sense to have a feature that allows a device to tell the FlyWeb client (right term?) what it's capabilities are, and allow the client to build an interface that supports those features. Potentially allowing for multiple devices on a single page.

Is this sensible for FlyWeb itself to be doing, or should another project handle this sort of thing?

[kannanvijayan-zz]

I understand the motivation for this, but I'm not sure if the implementation is compatible with general web principles.

There are a number of existing proposals to do IoT using device-type profiles and establishing protocol standards for different schemas of information (e.g. a data schema for thermostats, one for lights, one for speakers, etc.).

The problem I see with that approach is that it requires the standard to assume the responsibility of knowing all the types of interactions possible. A new device with new capabilities which doesn't have a supported data schema in the standard won't be able to expose its functionality (or will be forced to come up with its own ad-hoc schema).

The nice thing about the web app model is that the client (browser) operates as a general purpose runtime, and doesn't have to know or care what type of device it's talking to.

That said, the use case motivation (multiple devices on a single page) can still be achieved by relaxing our understanding of a page. We assume currently that a single browser window/tab always shows content from a single remote origin. What if a special "dashboard" browser window tiled its draw area, and allocated each tile to a different FlyWeb device. It would be similar to having a page with multiple iframes embedded in it pointing to different origins.

We could still load a full web frontend from each device - the frontend would just be rendered into a smaller "card-sized" view rather than a full page.

The issue with heavyweightness that your raise is a good point. One potential answer to this is to point out that HTTP is actually a pretty lightweight protocol if you strip out a lot of the extensions (e.g. gzip compression, keepalive support, etc.). A simple parser and responder shouldn't add more than a few kb of code overhead, especially if optimized for codesize rather than raw speed.

A good chunk of the overhead in modern web servers comes from the fact that they try to optimize request throughput/latency for high-load use cases on top of powerful systems. They use a lot of power-hungry techniques (thread pools, process pools, preloading, etc.) to support hundreds-of-requests-per-second scenarios. A local-area service available only to people in the vicinity doesn't need to worry about scaling issues nearly as much as a web service available to a few billion people. The servers could be built a lot more lightweight and low-overhead.

That said, the above reasoning is mostly an educated guess.

[Faeranne]

Being the current developer for TheThingSystem, my main reason for asking this is that on assumed purpose of a network of things is some level of smarts. With that in mind, finding a way to boil down devices into their base features becomes a requirement, and is whai I am currently working on. So, with that in mind, and assuming such a spec/schema is developed, would the above idea still be unreasonable? Or would it make more sense to include it?

All that aside, you make a fair case.