Thanks to some creative brainstorming from @geekgonecrazy, I have coined this idea "Rocketlets" instead of plugins or integrations as those two terms are extremely generic and can mean a lot of other things to other people while using our own term will let us define what it means for us and other people.
The goal of Rocketlets is to allow people to fully customize how their Rocket.Chat instance works without having to fork Rocket.Chat along with Rocketlets being fully documented with how it works including the code being in TypeScript so that everything passed in has a type (and we can use decorators). The ability to customize a Rocket.Chat instance was started with integrations and how they now have different triggers (events) which can fire them, however even those are currently limited as they just allow reacting to a trigger after it has happened. With Rocketlets my idea is to have two different actions per trigger (event) which will allow them to customize the Rocket.Chat functionality.
Let's take the message sending event for example. A Rocketlet there can define pre_messageSent
and post_messageSent
methods. The pre_
methods will be called pre/before saving of the event and thus before the events are officially considered sent to others. The post_
methods will be called post/after the saving of the events. Thanks to using TypeScript, each method will be able to use a decorator which will specify the priority of the method on handling the event with a range from LOWEST to HIGHEST and then MONITOR. The lowest items will be called first and the highest will be called last, this way the highest priority items have the last say on an event than the lowest.
Incoming webhooks will also be merged into Rocketlets and they will be just another method that is call on the Rocketlet. When a Rocketlet gets created it will have a url generated for it which can be called (GET, POST, PUT, DELETE, etc) and use the data in along with providing data out. The method on the Rocketlet webhook_event
will be called with two parameters passed, "method" and "request".
Now for the client, I want to allow Rocketlets to be able to fully utilize the action button type of message, along with defining tab bar functionality as you have highlighted in the above comments, along with full control over reactions and everything else. Another piece that Rocketlets will be able to do is provided new slash commands to the clients and show a preview of items to the client, see my comment here for an example.
Each Rocketlet will be able to provide a list of settings it provides to the user which the user can configure. The settings provided should have defaults unless the Rocketlet wants some to be configured before it can be enabled. This will allow for high configurability, for example let's say we create a GitHub Rocketlet and we want the user to be able to select which style of commits show up inside Rocket.Chat then they can select from a drop down either simple, extended, or advanced.
Eventually Rocketlets will get to the point that we can have a directory of Rocketlets that servers can click a single button to install them then elect to be updated automatically whenever a new Rocketlet comes out or manually approve the update. Each Rocketlet would then have a changelog so the users can see what changed between the versions inside of their Rocket.Chat. As a result of this global idea, each publicly available Rocketlet will need register with us, Rocket.Chat, to get an id however there will be a range of ids available for private usage so that private and public Rocketlets will never conflict with each other.
I am missing quite a bit of details. However, I wanted you to be aware of my idea as I noticied with your commit that our structure is basically the same and we would be duplicating work. I would be more than happy to work with you @mrsimpson so we can combine our efforts and get something crafted up that is simply awesome. Below is my base class idea for the server