<div dir="ltr">Hi Ted,<div><br></div><div>Thank for continuing to explore the topic here.<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 17, 2015 at 12:45 PM, Ted Gould <span dir="ltr"><<a href="mailto:ted@ubuntu.com" target="_blank">ted@ubuntu.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I think that I can infer from the rest of the text, but I want to double check, you'd expect the <i>type</i> to be known at the package build time, just not the configuration of that.</div></div></blockquote><div><br></div><div>I don't understand the question.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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?</div></div></blockquote><div><br></div><div>Capabilities comes from multiple places. One of them is certainly the gadget snap. About it being "adjustable", too vague and too early to tell.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div></div></blockquote><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div></div></blockquote><div><br></div><div>Yeah, we'll have nice APIs for that kind of thing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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:</div></div></blockquote><div><br></div><div>Right, that's why capabilities have a name rather than just a type.</div></div><div><br></div><div><br>gustavo @ <a href="http://niemeyer.net" target="_blank">http://niemeyer.net</a></div>
</div></div></div></div>