Support for composite datasources

[cgreenhalgh]

It should be possible to have composite datasources, i.e. logical datasources which are comprised of multiple primitive datasources (data streams). E.g the hue bulbs are currently several independent datasources (on/off, hue, brightness, saturation, colour temperature). This makes giving an app access to such a datasource tedious and error-prone (e.g. may accidentally select hue on one bulb and saturation on another).

This requires that

• drivers can express this relationship in hypercat, including some suitable indication of type.
• app manifests can express the desired composite datasource (e.g. type and/or sub-datasources)
• the app can relate the composite datasource and the primitive datasources with the information it receives from the CM
• permission are enforced appropriately.

I can imagine either an implementation in which the CM explicitly expands the composite datasource to the primitive datasources and uses the current system, or in which stores directly supporting composite datasources, e.g. through hierarchical structuring of the datasource ids.

[mor1]

Not sure I follow your last paragraph. Isn't it up to the driver author to determine what ends up in the driver's store (ie., which of the datasources), and then up to an app author to compose data from multiple stores as they see fit? Certainly there may be value in having some structuring of hypercat entries though, to enable (eg) discovery.

[cgreenhalgh]

With the current key-value store the key is the datasource id and the value is a single JSON object. Permissions (e.g. macaroons) are defined at the level of paths including the datasource id.

The second implementation option (which is probably more complicated and not immediately more useful) was the idea that datasource ids might be (e.g.) : and permissions might be given in terms of the : path prefix, which thereby gave access to all sub-sources.

I think the main requirement in the shorter term is a UI one, i.e. that the manifest->SLA process can allow someone to select a "hue lightbulb" (as a whole) and not worry about its individual data sources.

Partly I was also thinking about other structured stores, e.g. like Redis, where a single entry can be structured, e.g. a set, hash, but that is probably an orthogonal issue.