first (very rough) pass at implementing Slack engine #107
Conversation
|
@rougeth @nicoddemus Any issues with general idea or should I go ahead and write some tests? |
|
@bradshjg didn't have time to check it yet :/ But I had something different in mind about polling vs webserver vs websocket (webhooks). My idea was that bottery would give to each platform three basic "tools": An event loop (for the async tasks, used for polling for example), a session of aiohttp for API requests and a webserver (also aiohttp) so that we could configure platforms that get new updates from webhooks. What do you think about this approach? |
|
I can't really comment I think because I don't have experience with any messaging backends, but @rougeth general suggestion looks sound to me. |
|
@bradshjg we just merged the integration with Facebook Messenger, do you think we could do something similar with Slack? |
|
@rougeth I'll take a look at that implementation and get back to you soon, sorry about the delay |
|
@rougeth I took another look at both the Slack and Microsoft Teams Bot APIs (those are the two I'm most interested in implementing). As far as I can tell, neither offer http polling as option for getting messages the way that the FB Messenger and Telegram engines work. The realtime messaging API from Slack at least allows for the bot to act solely as a client (receiving events over a WS connection), but it doesn't look like that's possible in Microsoft Teams. Creating a server definitely seems to me a very big change. I'm going to look at implementing an interface very similar to Bottery's but using an http endpoint and message passing for async, I'll ping you if I get something working. |
|
@rougeth Whoops, looks like I'm wrong on both counts. I'll look at implementing them in the next couple weeks. EDIT: Sorry, I really should have paid more attention in general. It looks like bottery does support the idea of webhook mode. |
#3
There's isn't quite a 1-1 correspondence between Telegram users and Slack users, I'm not sure how we want to work that out.
The current behavior is to listen to DMs and message to any channel the bot belongs to. In the case of a channel it responds to the channel (I could see a case for making it configurable whether it sends "ephemeral" messages to users in the channel or to everyone).