Snappy capabilities, in baby steps

Ted Gould ted at ubuntu.com
Fri Nov 13 17:29:49 UTC 2015


On Fri, 2015-11-13 at 15:02 -0200, Gustavo Niemeyer wrote:
> On Fri, Nov 13, 2015 at 2:47 PM, Ted Gould <ted at ubuntu.com> wrote:
> > So from Zygumnt's thread it sounds like there's going to be a tag
> > cloud attached to each snap. I'm guessing that this is going to
> > include kernel, gadget and framework snaps. They'll export which
> > tags they support. Will the tags be centrally defined or are we
> > hoping for some sort of emergent behavior here? How will we handle
> > conflicting tags?
> The terminology in use is that there's a capability name which is a
> unique identifier in its context (e.g. the snap) and there's a
> capability type which defines its meaning. We want to make capability
> types extensible, but they must be centrally approved since there are
> security concerns associated with it.
>  
> > For the cases where versioning is important, how will that be
> > handled. For instance being able to support OpenGL could mean
> > standard GL of various versions or GLes of various versions. For
> > games which versions the HW can support can be very important.
> > 
> The capability type defines what behavior is allowed and expected.
> There will be metadata associated with the capability, so in cases
> where the capabilities are very similar they may end up being defined
> as a single capability type with differing metadata. In other cases,
> they may be different types.
So let me see if I understand using the OpenGL example. You'd expect my
kernel snap to look something like this?
name: teds-cool-kernel
capabilities:
  graphics:
    type: opengl
    versions: [gl2, gl3, gl4, gles2]
And then the application that required the capability to look like
this?
name: teds-super-modern-game
required-capabilities:
  graphics:
    type: opengl
    versions: [gl4]
Then how would the decision be made whether my game could install on my
kernel? Where is it defined that there would be an any or all
relationship with versions?
> > There was a mention of passing metadata, which way will the metadata transfer occur? Both? What is the lifecycle and policy for handing that passing of metadata? Does it require a particular format or is that to be decided by the framework and/or application involved in the exchange?
> > There will be a particular format and protocol for exchanging the data. We're not there yet, though.
Do you know if it is going to be two-way or one-way? If one-way, which
way?
Ted
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151113/fd386d87/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/20151113/fd386d87/attachment.pgp>


More information about the snappy-devel mailing list