BotMan 3.0 Feature Wishlist

This site is best viewed in a modern browser with JavaScript enabled.

BotMan 3.0 Feature Wishlist

marcel

Hi ,

since 2.x is already out for quite some time, I wanted to start thinking about new features and improvements that can find it's way into a 3.0 version.
Also, if you have any thoughts on the general architecture and how this could be improved: this is your chance.

Please do not request a driver for a different messenger service - these drivers are decoupled from the framework and can be implemented standalone.

christophrumpel

Nice!! I would like to rewrite BotMan testing with you Marcel. The framework is really great and we should provide more and better features to test even big enterprise applications. Maybe we can brainstorm together to see where and we could improve the given solution.

marcel

christophrumpel yes thats a good idea! The testing part is already quite good, but lacks extenaive documentation and examples. And you run into some trouble when you try to test more complex applications.

KarlisJ

I have some ideas about testing as well. Actually one PR is still pending ...

marcel

KarlisJ You mean https://github.com/botman/studio-addons/pull/15 ? I still don't like the fact that we have to require the Facebook Driver for this, so we should come up with something else for this.

KarlisJ

marcel Well we discussed that we should work on package discovery in way that these additional tester classes are loaded together with Facebook Driver

KarlisJ

If we are actually talking about v3 then I will not hold my thoughts and go wild
One thing that I really mislike about BotMan is the messy stacktrace in corversation because of serialization of callbacks. Also it makes impossible to use xDebug for conversations.
Even thou it is easy to read code using closures but it causes pain when debugging and also conversations can grow quite long thus making the code messy. (This can lead to conversation splitting which only works bad for overall architecture of app)

So I would propose to think about changing the way the conversations works.

My vogue idea:
The conversation class holds only the logic of what to do, what questions to ask, what to do accourding to some answer and so on.
Then we have Question class(I have always though that Question class is a bit misleading because it is not always necessary a question so not to confuse - I speak of something other then Question class we have in v2) which holds everything related to ONE question that conversation can use. There is a method that is called always and it basically asks the question. This method is similar to what we now have in conversation->ask only instead of having closure as second parameter it would receive a string method name that would be called as callback. This callback method is defined inside this same Question class. This way we do not serialize the callback rather then just point to it.

The Conversation class has properties that define the state of conversation. We store only that information and Conversation class have methods to understand that information. This way we do not do any serialization.

This would also be a gain for testing. Right now it is a big problem to test only last question in conversation you have to copy paste the testing code to get to that question. With this approach we could inject the state in conversation and have unit tests only for specific questions in conversation

marcel

KarlisJ I would really like to get away from serializing the closures too.
It produces a lot of problems and issues that we had to deal with (unable to serialize closure ...).
And I also ran into a situation where the "Question" class name was pretty misleading - because right now you can also just use it to send a text with two buttons outside of a conversation.

Right now we also accept callables instead of closures, so you can do:

$this->ask('question', [$this, 'answerMethod']);

I'd still want to support closures for regular hears methods though, just not inside conversations. The whole concept was a bit misleading in hindsight.

So yeah - even though this will be a pretty big breaking change, I think it'll be worth it to be able to create better conversation classes.

Edit:
Thought about this some more.
At the end we would have conversation classes that only hold the "flow" of the conversation, while the question classes control the specific logic of each question - correct?

I don't quite get how we want to control the flow though.

sebastian

Actually, I like the Question-Class-Idea. This would also make re-usability easy.

To go absolutely wild: How about an event-based-system?

BotMan::dispatch(new AskForEmailQuestion($somereference));

I have no idea how/if we can still pass the context and state of a conversation with this approach but I'd quite like handling of wrong user inputs in one dialog for email requests and only write it once per bot.

KarlisJ

I have to gather up my thought about the conversations so I will respond to that later.

Second feature that I suggest is something very similar to how Laravel handles notifications.

One of the best features of BotMan is its ability to have one codebase for multiple chatbot platforms at once. In the same time there are differences between these platforms - FB have templates, other have only images and some even dont have images. It would be great if BotMan would have a lets say Template class which could have methods for every driver returning the message spicific to that driver. Then if we would write $bot->reply(new CarouselTemplate($param1, $param2)) the bot would send FB template with elements to FB messenger but for Telegram user send some other structure like the images needed + buttons or whatever works.

The idea is that we have specific meaning for every message we send to users and for each driver there are different ways to communicate that meaning. So it should be as built in function.

And it really would not be hard to implement that (actually it could be easyly implemented in v2 using simple check in beginning of reaply() method)

christophrumpel

I already had some similar thoughts and heard of other frameworks using a similar approach to what @KarlisJ mentioned. It is just quite complicated because how would you treat the FB airplane ticket template? Or with a Facebook Template where you can set a "cover photo". Every driver and message can have very specific fields which makes the whole scenario quite difficult.

marcel

christophrumpel I think what @KarlisJ suggests is something like this:

<?php

class CarouselResponse extends Response
{
    
    public function toNexmo()
    {
        return OugoingMessage::create('This is for Nexmo');
    }


    public function toFacebook()
    {
        return ButtonTemplate::create('This is a button template')
            ->addButtons([
                ElementButton::create('Button')
                ->url('https://botman.io')
            ]);
    }
}

KarlisJ

marcel christophrumpel Marcel explained exactly what I meant. There's also a constructor to pass all the necessary info. And then in reply() method if the message is instance of Template then we check which driver is this and call according method.

https://laravel.com/docs/5.5/notifications Here is good read how Laravel implements the feature

christophrumpel

Ah ok, so it is not BotMan who is trying to map the carousel to every driver, it is the developer who decides. Got you now. Sound promising! Like it.

KarlisJ

Ok, next idea

Currently the getUser() method works through cache. It would be great if we could have several drivers for that so that developer could for example put in config/botman to use Eloquent, defy the fields and model name etc and then getUser() would return the eloquent model.

The default could stay as it is right know - the cache driver. But we could give the developer the freedom to implement the interface to create their own needs.

It actually could be just Interface called UserDriver with three methods - saveUser, getUser and something like injectBotmanParameter (the last would be called by BotMan class and provide the class with current driver name, recipient id etc, like some kind of constructor)

lkloon123

hope to get a discord driver

fwartner

RocketChat would also be nice!

zaherg

Maybe make it a Lumen friendly, I know many people here may not like Lumen, but I think it can be a good framework for botman, since it has most of the features which required by botman, and will make it even easier to have the bot alone as a small service without shipping everything Laravel provide which you may (or may not) user

KarlisJ

zaherg "since it has most of the features which required by botman" Botman doesn't require anything from Laravel. It is a standalone chatbot framework. Botman Studio is a ready Laravel based boilerplate but the steps to use Botman in Laravel are very simple ones. There is no problem right now to use Botman with Lumen.

WyriHaximus

Been playing a bit with botman in combination with a react/http server and would love to see full PSR-7 support where you pass in the request into $botman->listen() and get a PSR-7 response back. A, hopefully working, consequence of that would be the reuse of the $botman instance across requests.