Lightweight and distributed Yetibot instances per service
kaffein opened this issue · comments
A (crazy) idea popped into my mind while thinking about the way we interact with Yetibot from the main channel. I did not have the time to dive into the technical details but I thought it would be cool to just share it here for fun :)
At the moment when we talk to Yetibot, we have to use a prefix (defined in the configuration file config.edn) and then we type the command like so :
!aws s3 ls my-bucket-url-here
What if instead, we use the lingua franca of the chat platform. In particular, I am thinking about the use of @ for mentioning a user from the main channel, user here would be our Yetibot instance. We would then have a connected Yetibot instance identified as aws responding to the command :
@aws s3 ls my-bucket-url-here
In terms of User Experience, I think it can be cool. But here is the real idea, and to some extent a consequence of the first idea above.
If we elaborate on this interaction idea, instead of having a single instance of Yetibot, we would then have multiple more lightweight Yetibot instances, each responsible for only one specific service or feature (github, aws, twitter etc.). Yetibot would then become a kind of framework/template providing a layer of abstraction on top of the underlying platform (as is already the case with Yetibot.core) allowing contributors to focus on implementing only the core logic of their service.
These are just some ideas and again I did not really dive into the technical feasibility given the current implementation. But one concern that is obvious to me is that composing commands/services as we have it now would not be possible since we would then have totally distributed processes (some kind of messaging maybe ?).
That was it :) ...
Thanks
Thanks for posting @kaffein❗
Very interesting proposal. If we did have various distributed Yetibots, maybe a common/shared/parent instance could coordinate between them somehow, like @yetibot. I like the idea of lightweight processes that handle very specific commands, especially in the case of aws where the amount of things it can do is quite large.
This is also consistent with the recent plugin architecture changes that allow command-specific plugins like yetibot-kroki to exist as an isolated code base.
Awesome, I also like that idea of having a coordinator 👌