Re: Browser as an universal client for IoT

I'd rather see us push for support for mDNS on Android than try for something else.   It's close to being universally supported... except for Android (and it seems the problem is only in the browser).

Regarding .local, recently Ubuntu started nattering at me about my use of the .local domain, going as far as disabling it automatically.   So there's another issue there to dig into.   However having a special (and standardized) domain for locally-discovered devices is useful.  Cleaning up and standardizing the use of .local (helping to avoid certain allergic reactions to it) would be helpful.

Michael

On 2016/10/25, at 2:13, Jason Proctor <jason@mono.hm<mailto:jason@mono.hm>> wrote:

i don't think any of the Android browsers support mDNS (and it's high time .local was a standard, IMHO!) but the NsdManager class makes API level integration straightforward. works for me.

(btw i think there is an Android kernel issue which prevents mDNS multicasts from being received locally, which is quite annoying. affected me on FirefoxOS (which uses the Android kernel) also.)



On Mon, Oct 24, 2016 at 9:56 AM, Mccool, Michael <michael.mccool@intel.com<mailto:michael.mccool@intel.com>> wrote:
Note that Android does not support mDNS... a constant source of frustration for me.   At least in every version I've tried up to now.
But I don't consider this a blocker.
Michael McCool

On 2016/10/25, at 1:39, Jason Proctor <jason@mono.hm<mailto:jason@mono.hm>> wrote:

Safari at least implements the basics - i think there's great value in being able to walk up to any browser on the network and type "oven.local", for example, and that indeed is how our Sensible framework works :-) but as far as i know, no browser natively implements bringing back lists in return for searches - though using the Web UDP API works fine.

seems like the pattern for newly installed devices is for them to make Wifi networks and then allow clients to join them in order to configure access to the main network.

one thing i've not sorted is how to determine proximity to a device. Wifi isn't much use in this area. does any variant of Bt give an idea of proximity, maybe based on signal strength? would be nice to have a WoT volume knob figure out which device to control based on proximity, for example.





On Mon, Oct 24, 2016 at 9:20 AM, Benjamin Francis <bfrancis@mozilla.com<mailto:bfrancis@mozilla.com>> wrote:
Having mDNS support in all browsers/operating systems would be a great start! This allows a device or gateway to broadcast a Thing's existence on the local network so that a browser can discover it.

As Scott mentions, physical web beacons can also provide a discovery mechanism for the user agent which doesn't require the Thing to already be  connected to the the same LAN.

Ben

On 23 September 2016 at 16:35, Jason Proctor <jason@mono.hm<mailto:jason@mono.hm>> wrote:
this is our approach too -- run web/websockets servers on the Things and use mDNS to find them. works great for us, at least!


On Fri, Sep 23, 2016 at 2:02 AM, 전종홍 <hollobit@etri.re.kr<mailto:hollobit@etri.re.kr>> wrote:
Hi All,

I’d like to propose one of different view point for WoT.

I think we need to start to find the way how can we use the web client(UA or browser) as an universal IoT client.

http://www.slideshare.net/hollobit/web-browser-as-universal-client-for-iot


How do you think about starting the idea scratch actions for web client as IoT browser in the WoT IG ?

Best Regards,

— Jonathan Jeon