Fixed channel.destroy() not allowing the user to resubscribe

[HuFlungDu]

I noticed that when you call channel.destroy() in the javascript client, it will unsubscribe from the channel, so the server will no longer send those channel events to the client, but it will not remove the channel from the WebSocketRails.channels collection. Essentially what this means is that if you create a channel, call channel.destroy(), then attempt to recreate the channel, the dispatcher will give you back your original, now closed channel, and will not create a new one, meaning it will not re-subscribe to the channel, so the server will not send events to this client. This is a problem for me because I have multiple widgets on the screen controllable by the user, and each widget might subscribe to a channel, and destroys it's channel when it's removed, so if the user creates, removes, then creates the widget, it will not get any updates.

I know a solution to this would be to use WebSocketRails.unsubscribe() instead of channel.destroy(), and maybe it's just that I'm thinking about it wrong, but it seems to me that destroying the channel should free it up to be opened again.

So I made it where instead of using a shared object for all the instances of a channel, every time you call dispatcher.subscribe, it will create a new channel object and add that to a pool of channels that it uses instead of a single channel, and if the pool is empty, calls the subscribe method to let the server know it wants to subscribe. If there is already something for that channel, it just adds it to the pool without telling the server about it. In addition, when you call channel.destroy(), instead of immediately unsubscribing from the server, it now tells the dispatcher to remove itself from the channels pool, and if it is the last one in the dispatchers channels pool, then the dispatcher will run the unsubscribe event and remove the channel's name from the channels object, allowing the user to resubscribe at a later time.

This is useful for long running backbone style apps with lots of channels, where you don't want to bog down each page with all the events from every page that the user has visited so far this session, or maybe want to remove certain callbacks from a channel with an even name without removing all callbacks for that event name.

The only major downside to this is that it creates kind of a tight coupling between the channel and the dispatcher, but without moving the destroy channel function from the channel to the dispatcher I can't think of a way to loosen up on that.