Snappy capability types and attributes

[Gustavo Niemeyer]

Hi Ted,

Thank for continuing to explore the topic here.

On Tue, Nov 17, 2015 at 12:45 PM, Ted Gould <ted at ubuntu.com> wrote:
>
> I think that I can infer from the rest of the text, but I want to double
> check, you'd expect the *type* to be known at the package build time,
> just not the configuration of that.
>

I don't understand the question.

I'm concerned about the types because that will be the difficult part from
> the developer experience perspective. How they get a list of types and what
> the properties are so that we can generate reasonable errors if they misuse
> them.
>

It's hard to do dramatically better than documentation and examples here..
if an application takes a serial port and thinks it's an audio device, bad
things will happen, and it may not be obvious.


> It seems like this would be done by the gadget snap on most devices, no?
> So is there associated YAML that the gadget snap would have for configuring
> the board layout? Do you expect it to be adjustable by device owners or
> only those with a "developer mode" gadget snap?
>

Capabilities comes from multiple places. One of them is certainly the
gadget snap. About it being "adjustable", too vague and too early to tell.


> I'm still against the hook. It seems to me that you're trying to use
> exec() as a form of IPC when we already have a better one implemented,
> REST. Marshalling variables through the environment is well understood, but
> also very tired.
>

A REST API is just an API. How do we allow snaps to react to events?  Would
we implement a server doing HTTP polling on every snap?

We most likely won't be using environment variables for state transference.
Please note Zygmunt's email is an unreviewed strawman, rather than
documentation for how it's going to work.

On place where hooks fail is if the config file needs to be regenerated,
> please also provide a mechanism to "query my current capabilities" so that
> I can check on them and rebuild the config file.
>

Yeah, we'll have nice APIs for that kind of thing.


> Also, it seems like your proposal doesn't take into account multiple
> sockets on the application side. For instance, if my application was "say
> yes or no over serial" I might want to hook up one serial port to one
> socket and another to a different. Something like:
>

Right, that's why capabilities have a name rather than just a type.


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