Houston::Connection.open opens and closes socket with each call about houston

[gertig]

I believe other gems that have tried to fulfill this requirement have gone the route of daemonizing the connection, sounds like a lot of work for low return. Maybe if you are sending hundreds or thousands of APNs then houston is a good fit but if you're planning on sending millions then you might want a service?

@matt I'd love to hear your thoughts on this it's something I've wondered about too.

[aevernon]

I don't think it'd be much work. You would need two hashes in Houston::Connection -- one for the socket variable and one for the ssl variable. The key to the hashes would be the options parameter.

[aevernon]

For those interested, the grocer gem attempts to reuse connections to Apple's servers.

[mattt]

There's nothing inherently wrong with how Houston does its connection opening / closing—in fact, it's a Ruby convention to have a block parameter yielded to between setup and destroy (e.g. File#open).

Houston::Client doesn't attempt to do anything smart with pushing messages, as it's optimized for ease-of-use. However, if you wanted to keep the connection alive, you could rather easily make it so that the block executes indefinitely, keeping the connection open. This feels like the right approach anyway, as async / runloop / eventing code varies quite a bit across different applications (it may be useful to have a few documented examples of Houston integrating with something like Resque or Rails 4.0 queue)

All of that said, if you or anyone had a pull requests with suggestions on how this could be done better, I'd definitely like to see that.