<html><head></head><body><div>On Tue, 2015-11-17 at 13:10 -0200, Gustavo Niemeyer wrote:</div><blockquote type="cite"><div dir="ltr"><div><div><div class="gmail_extra"><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 type="cite"><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><br></blockquote><div><br></div><div>I don't understand the question.</div><div><br></div><blockquote type="cite"><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><br></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></div></div></div></blockquote><div><br></div><div>I think our serial port example is getting a bit tortured at this point, but let me try one last time with it :-)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote type="cite"><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><br></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></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote type="cite"><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><br></blockquote><div><br></div><div>Right, that's why capabilities have a name rather than just a type.</div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Ted</div></body></html>