<html><head></head><body><div>On Thu, 2016-01-07 at 16:35 -0200, Gustavo Niemeyer wrote:</div><blockquote type="cite"><div dir="ltr">On Thu, Jan 7, 2016 at 1:05 AM, Ted Gould <span dir="ltr"><<a href="mailto:ted@ubuntu.com" target="_blank">ted@ubuntu.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote type="cite"><span class=""><div>This sucks: "A Unity Application is a Snap Application that has…"</div></span></blockquote><blockquote type="cite"><br></blockquote><div><br></div><div>Yeah, I wouldn't write that either. I would instead say that a unity application ships in a snap. Unity applications, command line applications, graphic applications, service applications.. these are all applications. You can ship any of these applications inside a snap. Seems to feel good.<br></div></div></div></div></blockquote><div><br></div><div>I think that sounds natural, and the YAML should look the same. Let's as a strawman imagine that we encoded that as a key in the YAML directly.</div><div><br></div><div><font face="monospace">apps:</font></div><div><font face="monospace">  mycmdline:</font></div><div><font face="monospace">    command: dostuff</font></div><div><font face="monospace">    type: command-line</font></div><div><font face="monospace">  mydaemon:</font></div><div><font face="monospace">    command: dostuff -d</font></div><div><font face="monospace">    type: service</font></div><div><font face="monospace">  mygui:</font></div><div><font face="monospace">    command: dostuff -g</font></div><div><font face="monospace">    type: gui</font></div><div><br></div><div>From this we can see what is common and what is different. Which fields make up an "app" and where the difference is. I think that, since we already have a scheme for expressing additional values in capabilities, it would make more sense to use that for defining the extra settings for things like services instead of using an explicit key like "type". For instance:</div><div><br></div><div><font face="monospace">apps:</font></div><div><font face="monospace"><div>  mydaemon:</div><div>    command: dostuff -d</div><div>    consumes: [ daemon ]</div><div>capabilities:</div><div>  daemon:</div><div>    type: service</div><div>    stop-command: dostuff -s</div><div>    stop-timeout: 5</div><div><font face="monospace">    optional: false</font></div></font><div><br></div><div>By having this type of framework in place to explicitly define which kind of app each item is, it makes it possible for people building on Snappy, and providing their own lifecycles, to also build on the terminology. I don't have a concern over specific syntax of the YAML as much as I'd like to ensure that the app is the core element and the extension of that element is done through a standard mechanism instead of magic keys.</div><div><br></div><div>Ted</div><div><br></div></div></body></html>