Snappy capability types and attributes

[Ted Gould]

On Tue, 2015-11-17 at 13:10 -0200, Gustavo Niemeyer wrote:
> 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.
I think our serial port example is getting a bit tortured at this
point, but let me try one last time with it :-)
I'm suggesting that if there was a property of the serial port type,
let's say baud rate, we could generate a better experience if we knew
the list of values at build time. So we could generate an error like:
"Value for 'baud-rate' of '96000' is invalid, must be one of: '9600',
'2400', etc." Which avoids a developer building a package, installing
it, and then finding out they didn't match just because they fat
fingered a zero.
So, my concern is that types would be entirely ad-hoc with the only
definition being "a key-value list of properties." We've done that with
interfaces before, it sucked. Being precise and upfront about these
things with developers makes the system easier to use.
> > 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?
I imagine the same way REST handles events on the web, by requesting an
"infinite file" that updates with status. This will have to be done
several places in the Snappy REST interface as it'll be needed for
things like status of downloading snaps for a GUI progress bar.
> > 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.
Cool. In the example they were only on the provider side not the user
side of the capabilities. But I realize the example was limited, wanted
to make sure they're on both sides.
Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151117/a185585b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151117/a185585b/attachment.pgp>