Capabilities and slots

[Gustavo Niemeyer]

There's also an important detail missing from that description which I
assumed to be known because it hasn't changed since we started talking
about capabilities, but for completeness it'd be worth talking about it in
this context.

A capability slot may only have capabilities assigned to it if both have
the same capability type. That's what defines compatibility between a
capability and a capability slot. The capability name and slot name are
local to the snap itself. As a concrete example, we may have a snap
providing a capability "pin-13" that is assigned to a capability slot
"led", so we can turn some led on and off when the pin goes high/low. Both
the capability and the slot must have a common type (e.g. "bool-file") for
it to work.



On Tue, Jan 19, 2016 at 5:55 PM, Gustavo Niemeyer <
gustavo.niemeyer at canonical.com> wrote:

> Hello snappy developers,
>
> Zygmunt and I just finished a good meeting where we polished the design of
> the REST API and the Go interfaces, reflecting sprint agreements and the
> needs we've outlined in the last couple of weeks.
>
> This will start to surface as pull requests in the repository imminently,
> if you're interested in more thoroughly reviewing those decisions. At a
> high-level, though, the interesting outcome is that we've settled down onto
> the following terminology and semantics.
>
> Capabilities always have a providing snap and a consuming snap. Even those
> that may feel like they should come "from the system", are actually
> associated with a providing snap. That's consistent with our new view of
> the  world, where everything comes from a snap. At some point we may
> introduce a "defaulting" behavior where we allow omission of information to
> do what's most expected in a given context (e.g. "pin-13" refers to
> "canonical-pi2.pin-13") but for the time being we'll keep this explicit in
> the interest of getting the foundation right.
>
> Capabilities and capability names are the way we talk about the providing
> side. The consuming side has capability slots, and capability slot names.
> Thus, when we say that "a snap has capabilities", we're implying it
> provides/offers features. When we say a snap has capability slots, we're
> implying it requires/consumes features. That asymmetry, originally
> suggested by Zygmunt, makes conversations, documentation, and APIs around
> capabilities much easier to understand.
>
> We still need to map the consequences of these decisions and the original
> agreements onto the metadata files. I expect that to take place in the next
> couple of weeks.
>
>
> gustavo @ http://niemeyer.net
>



-- 
gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160120/b8c88536/attachment.html>