Replace slack-api with slack-ruby-client, remove need for web API

[dblock]

The implementation of say is using the web client, which is wasteful at the very least. Replace the underlying library with https://github.com/dblock/slack-ruby-client, and reimplement say to use the websocket connection.

[lazyatom]

As I understand it, many of the advanced formatting and attachment aspects of messages are only available via the web (I.e. Non-websocket) API, and so there's some value in working with both APIs, despite the apparent waste. Am I mistaken?

[dblock]

I think 99% of the time you send plain messages with basic formatting, all of which works via the RTM API. I personally never needed anything else in my bots, but YMMV. Sometimes you want attachments. If anything, the web api is something like 10x slower at least.

[lazyatom]

Well, for my original use case the notifications all require attachments, so I must be hogging that 1% :-)

Maybe a good compromise -and a nice API - would be to check whether or not any of the options won't work using RTM and in that case fall back to the web API?

[dblock]

In slack-ruby-bot the default implementation of say just uses the RTM api's message, then if you want the other one you can do client.web_client, which is the same one as what you'd use to get the result from rtm.start. I tried to keep these two very distinct.

[lazyatom]

What are the benefits of slack-ruby-client over slack-api? I'm not wedded to my original choice…

[lazyatom]

Why might it be important that RTM and web message posting methods be kept separate, from a bot developer point of view?

[dblock]

I think the READMEs of the two projects speak for themselves, but I think of slack-ruby-client is what slack-api (aka slack-ruby-gem) should have become, but I couldn't get much attention from the maintainer to get my PRs merged.

Web and RTM are two different APIs, I expect a good client to map 1:1 to what the service is providing and not mix and match, and have documentation about what's going on.

There're some specific issues in real-time/client.rb that are more immediate, for starters the EM.start and EM.stop make it problematic when you run multiple instances of the thing.

[lazyatom]

I think it's important for a good library at the level of slack-api or your own slack-ruby-client to be faithful to the underlying API, but I don't think it's important for anything at a higher level to do so. My goal is to provide a useful abstraction, on top of what Slack offers, that helps people writing bots, and abstracting away some of the details of how a message gets sent seems valuable to me.

That said, I can see a decent argument for building on top of your ruby client - it does indeed look like some pull requests on slack-api are being ignored.

[lazyatom]

I've started exploring moving from slack-api to slack-ruby-client here: #9

Let me know if you have any thoughts!

[lazyatom]

Fixed in #9