On Saturday, 23 February 2013 at 21:33, Will Brady via Hallon wrote:
I'm a little confused on when you need to call process_events. Using the example that Allan Nørgaard Kristensen posted in his previous question:
Yes, the example Allan posted is a little weird, since #load (http://rdoc.info/github/Burgestrand/Hallon/Hallon/Loadable#load-instance_method
) will block until the object has been successfully loaded (or until the timeout is reached). The code `c = session.container; c.load`
will thus guarantee that the session container has loaded. The while-loop contents after that, `session.container.loaded? == false`,
will never run.
Calling session.login seems to not actually log you in immediately
No, it does not. Very few things in libspotify (and in effect, in Hallon too) are immediate, and pretty much everything is asynchronous by default. There is a Session#login! method that will wait until login is successful, or an error occurs.
So does load block and login not?
Yes. Loadable#load is one of the few methods that block (i.e. wait until a certain condition in libspotify is met). There are a few others; if a method is blocking it should be explicitly stated in the API reference for Hallon.
How can you call process_events continuously if c.load blocks and you never get to that while loop? For me, c.load hangs forever.
#load should never block forever and if it does, it’s a bug. It either blocks until the object has loaded successfully or, after `Hallon.load_timeout` seconds, raises a Hallon::TimeoutError.
With all this: process_events is called for you on the blocking methods, but it needs to be called in order for libspotify to be able to do any work (and it’s part of libspotify). libspotify was really built with an application that has a main loop in mind, for example a GUI application or node.js. In such an environment it would be much more natural to use libspotify. Hallon should really have been something more similar to eventmachine to make sense in ruby.