<html><head></head><body><div>On Tue, 2015-11-17 at 16:29 +0000, John Lenton wrote:</div><blockquote type="cite"><pre>On 17 November 2015 at 16:18, Ted Gould <<a href="mailto:ted@ubuntu.com">ted@ubuntu.com</a>> wrote:
<blockquote type="cite">On Tue, 2015-11-17 at 13:10 -0200, Gustavo Niemeyer wrote:
<blockquote type="cite">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?
</blockquote>
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
</blockquote>
so now instead of having a program that's called when and if an event
happens, there is are two programs running all the time in case an
event happens?
</pre></blockquote><div><br></div><div>Was more thinking that if the application implemented a service that service would adjust based on capabilities while they were added. I wouldn't expect an additional service for just communicating with Snappy. For command line utilities they could read their configuration when run. The difference there is whether you read and parse a file or whether you read and parse a request to Snappyd. I don't know the numbers, but I imagine they're not significantly different in performance.</div><div><br></div><div>Frankly, with some of the flash in these embedded boards an HTTP request may be faster than a config file read ;-)</div><div><br></div><div>Ted</div><div><br></div></body></html>