Alpha Feature

[arist0v]

So we should start by decding wich feature we would focus on for a first Alpha Version. So we could start design and code base on this need and extend feature on the second alpha version.

There is what i suggest:
-Adding a single Gateway
-Generating a default dashboard with all thing and property without option to choose(like the gateway webgui dashboard)
-Controlling Thing and property in a similar way of the Gateway webgui dashboard

[arist0v]

Anyone have suggestions on the first alpha version feature?

[benfrancis]

I've created a product backlog with a suggested order of implementation of user stories suggested so far. Below are a couple of areas I think we need to discuss.

Things vs. Gateways

One thing we need to discuss is whether to start with features to add individual things, or add a whole directory of things (i.e. a gateway). I know that @arist0v is thinking that we should start by adding a gateway and that does make sense for existing users of WebThings Gateway who already have a collection of things. However there are a couple of reasons why I think it might make sense to start with adding/removing individual things:

1. So that the app is useful to people who don't use WebThings Gateway. It would enable users to directly monitor and control individual web things without the use of a gateway, whilst also being compatible with the things hosted by a gateway. That would include web things created using the WebThings Framework, but also other W3C WoT implementations, which will really help with the standardisation process.
2. Because there's already a standard for how to add an individual thing (by its Thing Description URL), but the standard for how to add a directory of things (i.e. a gateway) is still in progress. When adding an individual thing we can parse metadata about the thing from its Thing Description, but we don't yet expose a Directory Description for the gateway. See Provide a Thing (Directory) Description for the gateway gateway#2927. We could try to add 1.x gateways by their /things endpoint, but that doesn't provide any metadata about the gateway itself, is currently non-standard, and will change in WebThings Gateway 2.0, which leads me to the second point...

1.x vs. 2.x

We should also decide whether we want to skip directly to implementing the upcoming W3C WoT Thing Description, WoT Profile and WoT Discovery specifications which I'm currently in the progress of implementing for WebThings Gateway 2.0 on the master branch of the gateway repository, or whether we also want to be backwards compatible with WebThings Gateway 1.x, which uses the old non-standard Web Thing API.

I'm personally more interested in implementing the W3C standards, because having a general purpose Web of Things client is useful even beyond the WebThings project and is something that's really missing in the WoT ecosystem right now. However, being compatible with WebThings Gateway 1.x makes the app more immediately useful to existing WebThings users and we don't yet have a date for the 2.x release which is a lot of work.

If we choose to try to support both WebThings Gateway 1.x and the W3C WoT standards (including WebThings Gateway 2.x) then we'll need to take care to provide cleanly separated code paths for W3C-compliant devices and non-compliant devices as we are doing for the gateway by having a separate Thing URL adapter and WoT adapter. We'll also need to bear in mind that once WebThings Gateway 2.0 is released, the old 1.x client code will stop working, and we don't want to be in a position where the existence of the Android app holds back the WebThings Gateway 2.0 release because the app isn't yet ready.

What do you think?

[arist0v]

So after a 20 min drive to my daughter school this morning, i think i have a good idea on how to handle this.

I think we should change a little bit our way to see the apps. Instead of adding a "gateway" or a "things" or a "directory" what if we add a "source", a source object could be :

• a 1.x Gateway
• an individual things(ex bluetooth led strip i have in my room)
• a WoT Directory, Adapter, Things or etc...
• maybe in the long run we could even add Google Home device

We could maybe also add a "plugins" feature that allow to add more source plugins, so we could start focusing on a basic source, the app will support Out of the Box, and then create plugin for Gw 2.0 , and any other source we want to add. So it will make the app more usefull, exemple if someone produce a home assistant source etc....

It get us covered of working multiple option and always having the app ready and not outdated by new stuff.

So if all Source a an addon, then we will be able to adapt the app in the future and with maybe past or outdated deveice(insteon could be a good exemple of that)

Since a Dashboard will be just a "view" of multiple things from same or different source, it will always then be usefull.

I suggest we keep working in an "immediate" working situation, since my goal for the app was to fullfill a need(having some old phone and tablet used as room control) and that i already have some hardware and devices to work based on a 1.X gateway then add a 2.x source later and other option so the work we did isn't lost, and it's easy to cancel 1.X feature lather by banishing 1.x addon from the app.

(i'll hope my idea are as clear here than in my head)

[arist0v]

doing some more research, we should work with someting like on-demande feature for all "source".

• the native source will be install-time feature(so always there)
• the addition source will be on-demande and be available from an add-on page in the app.

Tell me what you think about that

This will also help the app to be more modulare and easily adaptive. we could easily add and remove feature, (like gw 1.x) or communitu feature that are outdated and not maintain by the owner.

some documentation:
https://developer.android.com/codelabs/on-demand-dynamic-delivery#0

[benfrancis]

Thanks for sharing your thoughts @arist0v.

In order to maintain focus and avoid feature creep I feel quite strongly that the WebThings app should ultimately only be used to manage web things. That includes everything which can be described by a WoT Thing Description, which includes WoT directories.

I would rather not go down the route of having installable add-ons for the mobile app, because that is essentially turning the mobile app into another gateway and we already have a gateway. By definition a gateway is something which allows data to flow from one network to another, and there practical reasons why it's better for that gateway to reside on an always-on device like a hub or a smart display rather than a mobile device like a smartphone or tablet which by its nature may not always be powered up or connected.

So in my view the WebThings app should only talk to web things, including those exposed by WebThings Gateway and those created using WebThings Framework or other WoT implementations. If you want to bridge a non-WoT device to the Web of Things then you should use a WoT gateway like WebThings Gateway.

With all that said, the practical reality is that WebThings isn't going to support the emerging W3C WoT standards until 2.0, so in the meantime I think it's totally reasonable for us to support adding devices (and directories of devices) using the Web Thing API.

I think we agree that we want to support both things and directories of things and both WebThings 1.x and 2.x. The question is just what order we implement those in.

I would like to implement support for the W3C WoT standards, but if you want to start with WebThings 1.x devices and gateways so it's more practically useful in the short term then I'm fine with that, as long as we have a path to cleanly migrate to 2.x which doesn't hold back that transition. That doesn't have to be through on-demand code modules, just cleanly separated code paths in the code base.

[arist0v]

I'm ok not gowing the on-demande way, since it could be a lot of work, I will still work on abstract class to implement data source, so i it will be easier later to add other source.

I still think we should go 1.x first, and after 2.x. Since anyway with the abstract class i'm creating, it would be easier to create other sources.

I maybe remember reading a phrase somewhere about using the app in an hotel room or other place that maybe the "thing" won't be matched to a gateway?. And is the WotT standard will includ bluetooth smart device?

Anyway without going the add-on way, working with the abstract class will make it able to be modular but not on an addon basis more on a coding basis. so i will work that way in separete module and abstract class so we would be able to easily extend feature and source.

I suggest open an issue about supporting WoT standard and a 2.X gateway so we could talk about it later and i could look how i could develop the source library related to this source.

So let's focus on 1.x to have something usefull then we could create a branch for the 2.X later to be ready to add support when the version will be launched.

[benfrancis]

'm ok not gowing the on-demande way, since it could be a lot of work, I will still work on abstract class to implement data source, so i it will be easier later to add other source.

👍

still think we should go 1.x first, and after 2.x. Since anyway with the abstract class i'm creating, it would be easier to create other sources.

OK, but just note that there's an outside risk that WebThings Gateway 2.0 gets released before WebThings App 0.1 and it's obsolete before it is released! Regardless of whether we support 1.x or 2.x first I think the main data entities should be Thing and Directory. An abstract "source" class may be premature abstraction as I don't expect there to be other types of sources in the forseeable future.

I maybe remember reading a phrase somewhere about using the app in an hotel room or other place that maybe the "thing" won't be matched to a gateway?

That's correct, not all web things have to be hosted by gateways. Devices can be self-describing web things.

And is the WotT standard will includ bluetooth smart device?

No, the WoT standard only covers internet protocols which have a URI scheme, and for WebThings that's restricted to web protocols. Any other protocol like Bluetooth requires a gateway (like WebThings Gateway) to bridge it to the internet and the Web of Things. We may use Bluetooth beacons for discovering nearby web things though. See https://w3c.github.io/wot-discovery/#introduction-direct

I suggest open an issue about supporting WoT standard and a 2.X gateway so we could talk about it later and i could look how i could develop the source library related to this source.

The 2.x API will be very similar to the 1.x API, just following the standardised specifications from the W3C WoT Profile and Web Thing Protocol instead of the WebThings-specific Web Thing REST API and Web Thing WebSocket API. It will also be easier to add and manage a whole directory using the Directory Service API.

So let's focus on 1.x to have something usefull then we could create a branch for the 2.X later to be ready to add support when the version will be launched.

I'm OK with that.

[arist0v]

OK, but just note that there's an outside risk that WebThings Gateway 2.0 gets released before WebThings App 0.1 and it's obsolete before it is released! Regardless of whether we support 1.x or 2.x first I think the main data entities should be Thing and Directory. An abstract "source" class may be premature abstraction as I don't expect there to be other types of sources in the forseeable future.

maybe we won'T add any other source yet, but it will allow to be modular and ready if we made some other change, since it will just cover some basis so if we need to one day create a version 3.0 for the gateway or stuff it will be easier, i think making it the right way first could be a good idea even if we don't use it yet or at all. I Think it won'T change anything to have an abstract class that aren't use on anything then just putting all the code in the same class and having to change everything later if we find out we need it.