# How to send blobs or streams in the WoT?

**URL:** <https://discourse.mozilla.org/t/how-to-send-blobs-or-streams-in-the-wot/32014>\
**Category:** WebThings\
**Created:** [September 23, 2018, 8:51pm UTC](https://discourse.mozilla.org/t/how-to-send-blobs-or-streams-in-the-wot/32014 "2018-09-23T20:51:02Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jaller94](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/jaller94/32/24189_2.png) [@jaller94](https://discourse.mozilla.org/u/jaller94)\
**Post date:** [September 23, 2018, 8:51pm UTC](https://discourse.mozilla.org/t/how-to-send-blobs-or-streams-in-the-wot/32014/1 "2018-09-23T20:51:02Z")

</div>

For now the Web of Things API seems to focus on simple types when sending properties, actions or events. I have seen booleans, numbers, integers, strings and colours (which are RGB strings).

When looking at current devices in the IoT realm, I see home automation that also sends pictures, audio, videos and streams of such. The data can either be produced in the network (e.g. a camera at the entrance door) or on the Internet (e.g. an online radio).

Would a gateway proxy these blobs/streams, as it does with simple values?  
How about sending URLs to the content? What if the target device can’t reach the source or the source requires some authorization?

Use cases:

- I want to get a notification when the house alarm goes off with a photo of the front door.
- When shopping, I want to check the content of the fridge via the fridge cam.
- I want to tell the TV / Media Centre (e.g. Kodi) to play a video from the NAS. (Can we control DLNA via WoT?)
- I want the internet radio to play a radio station in the morning. The WoT gateway could have rules for news on weekdays and calming tunes on the weekend.

Is sending these data types within the scope of the WoT standard? I think it should be.  
How much is WoT focusing on home automation for end-customers vs. automation of 😏every-Thing?  
Is there a place to bring in my ideas around these forms of data?

---

<div class="post-metadata">

**Author:** ![mstegeman](https://avatars.discourse-cdn.com/v4/letter/m/b782af/32.png) [@mstegeman](https://discourse.mozilla.org/u/mstegeman)\
**Post date:** [September 24, 2018, 1:24am UTC](https://discourse.mozilla.org/t/how-to-send-blobs-or-streams-in-the-wot/32014/2 "2018-09-24T01:24:37Z")

</div>

We’ve had some people send still images and other binary content as base-64 encoded strings. While this is not super efficient, it does work with our JSON-based descriptions. Another option, as you said, is to include a URL to the image/stream/etc. I think this is totally valid, as you’re still sticking with web-based protocols.

Some of your use cases don’t really need this functionality at all. For instance, playing an internet radio station could be as easy as setting a string property (station) and sending a play action. The same goes for the media center.

However, there certainly are cases where streaming functionality is required, not the least of which is cameras.

We’re still trying to work through security standardization for the spec. The W3C has done a [fair amount of work](https://w3c.github.io/wot-thing-description/#sec-security-vocabulary-definition), but that’s far from finalized. For right now, you could bridge existing hardware and services by writing a standalone web thing (or gateway add-on).

It would be worthwhile to file issues to our repos, [here](https://github.com/mozilla-iot/wot) and/or [here](https://github.com/mozilla-iot/schemas), especially if you have some property descriptions/schemas that you think would be capable of handling these use cases.

---

<div class="post-metadata">

**Author:** ![benfrancis](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/benfrancis/32/21346_2.png) [@benfrancis](https://discourse.mozilla.org/u/benfrancis)\
**Post date:** [October 3, 2018, 11:25am UTC](https://discourse.mozilla.org/t/how-to-send-blobs-or-streams-in-the-wot/32014/3 "2018-10-03T11:25:29Z")

</div>

I think this is an argument for [changing the href of a property into a links array](https://github.com/mozilla-iot/wot/issues/73) (like the current forms array in the W3C spec but links), so that you can provide a link for a property with an alternative MIME type to JSON, for example:

```auto
...
  "properties": {
    "image": {
      "links" [{
        "href": "/things/lamp/properties/image",
        "mediaType": "image/jpeg"
      }]
    },
  }
...

```

Note that `type` can be omitted in this case.

This solution was also recently [proposed](https://github.com/w3c/wot-thing-description/issues/223#issuecomment-422018047) for the W3C spec.

This would also allow for other [binary encoded data](https://github.com/mozilla-iot/wot/issues/41) formats.

I have filed an [issue](https://github.com/mozilla-iot/wot/issues/108) on the Web Thing API specification regarding binary properties.

---

<div class="post-metadata">

**Author:** ![jaller94](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/jaller94/32/24189_2.png) [@jaller94](https://discourse.mozilla.org/u/jaller94)\
**Post date:** [October 5, 2018, 7:36am UTC](https://discourse.mozilla.org/t/how-to-send-blobs-or-streams-in-the-wot/32014/4 "2018-10-05T07:36:33Z")

</div>

Is there a concept how updates for links’/forms’ content would be propagated via HTTP and Websocket?

The current W3C draft does not touch the topic as part of WoT.  
I guess for streaming content there is no real time when the content updates, but for a webcam that operates on an interval this would be interesting.

---

<div class="post-metadata">

**Author:** ![jaller94](https://sea1.discourse-cdn.com/flex001/user_avatar/discourse.mozilla.org/jaller94/32/24189_2.png) [@jaller94](https://discourse.mozilla.org/u/jaller94)\
**Post date:** [October 5, 2018, 7:37am UTC](https://discourse.mozilla.org/t/how-to-send-blobs-or-streams-in-the-wot/32014/5 "2018-10-05T07:37:28Z")

</div>

For a gateway like Mozilla Things I see it as a useful feature to proxy local link/form URLs to authenticated clients.

For that purpose I suggest for the gateway to point link/form URLs at itself.