Capabilities and slots

Gustavo Niemeyer gustavo.niemeyer at canonical.com
Tue Jan 19 19:55:35 UTC 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20160119/b25abbc8/attachment.html>


More information about the snappy-devel mailing list