<div dir="ltr"><div><br></div>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.<div><br></div><div>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.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 19, 2016 at 5:55 PM, Gustavo Niemeyer <span dir="ltr"><<a href="mailto:gustavo.niemeyer@canonical.com" target="_blank">gustavo.niemeyer@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello snappy developers,</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div>