Move behaviors/index.js into a separate npm module

[ryzokuken]

@jywarren @ananyo2012 I think this is high time we took src/behaviors/index.js and make it a separate npm module.

When we started out, there were no "frameworks" as such for building effective chatbots in Node or chatbots in general, and we decided to begin writing one from scratch. In the process of writing a chatbot, we have started to develop and perfect not only a chatbot but also an underlying system of making the chatbot work the way it does. Because our chatbot is becoming more modular everyday, it is now possible to use the core logic of the bot inside the index.js file independently of how the bot is configured to behave.

Anyone can use the core logic along with a compatible interface and set of behaviors and make use of our architecture. Therefore, I would like to take this file and use it as a standalone module.

This would also allow more people to use and get involved in our project.

@jywarren we had already agreed to make it happen, but it's best if we agreed on a few specifics:

1. License: MIT or GPL (my pick would be anything that you'd like. I have known people in the Node ecosystem that usually stay away from using anything under a copyleft license but I understand that publiclab's stance is pro-GPL and would have no issues if you chose to use it)
2. Where to keep it: In the publiclab organization or as my own repo (my pick would be hosting as my own repo. This is because this would go farther to assert the fact that the library could serve the needs of multiple orgs and isn't something specifically for use at plotsbot only. Also, while you guys will still be involved in the decision making process and would be contributors, I would find it easier to push things/merge commits myself than on an organization repo. Also, that would allow people outside of publiclab to also contribute in full measure without having to do anything with the organization's other projects)
3. Name: I have been talking to the author of bot, but its unlikely he will pass on the name even though the project seems pretty much haunted. For the time-being, we could use node-chatbot and maybe shift to something more appropriate later by talking to the people at npm itself.

[ananyo2012]

@ryzokuken It is a good step to make the project grow. So you want to make the entire behavior module a separate npm package right? Or just the behavior/index.js into another module ?

About licencing and ownership I leave the decision to @jywarren but regarding permissions it will be the same even if you keep it a part of publiclab as what matters are the permissions to a repo not a Org.

[ryzokuken]

@ananyo2012 mainly the behaviors/index.js file only, because the behaviours are specific to publiclab. Anyone who decides to use our library would have to code their own behaviours.

I also have write access to the current repository, but I don't feel comfortable merging things unilaterally into publiclab's repos. I really do not feel entitled to do so. Plus, adding the repo someplace else would also allow more people to be added to that specific project. If a person has nothing to do with publiclab, and they are added to the module repo, it would feel wrong.

[ryzokuken]

@jywarren what are your thoughts on this?

[jywarren]

Hi, @ryzokuken - thanks for your clear, thoughtful and flexible proposal here. I'm going to ask for input from others, and I think there's no particular urgency to move forward on this just yet -- tomorrow is a holiday in the US, so perhaps we could focus on other things until later this week?

Thanks.

[ryzokuken]

@jywarren I concur. We have more important things to deal with, and hopefully the engine is already operating optimally. Let's finish up #51 (I have added the documentation, awaiting your approval in there) and a few other things before thinking more about this.

Thanks.

[ryzokuken]

@jywarren Let's start working on this?

[jywarren]

How would this relate to, for example, the behavior pattern we had discussed which would periodically poll, such as observing an RSS feed or API call? I also don't know where that conversation was, and think we ought to be sure it's captured in an issue. And would things like the GitHub interface plug into the plotsbot library or into the upstream generic bot library? Thanks!

…

On Sun, Sep 17, 2017 at 10:56 AM, Ujjwal Sharma ***@***.***> wrote: @jywarren <https://github.com/jywarren> Let's start working on this? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJxfttql3S90xB4NOJMc_92KvRTdRks5sjTMvgaJpZM4OLbPc> .

[ryzokuken]

I don't think the interfaces would be any specific to our codebase and thus would be open for use in any application making use of the upstream bot library. The shared resources (eg: Github) are specific to our behaviors and thus stay limited to our own codebase. The additional behavior pattern would be added to the core logic of the bot, it is not specific to plotsbot.

We should make another issue for that change and document all our discussions regarding it there.

I hope I was able to satisfactorily answer you. If not, please feel free to ask again.

[jywarren]

Cool, that sounds good. I meant specifically where we might have `require('github-interface')` for example - would that be in the upstream, and then required in turn into plotsbot but not directly?

…

On Sun, Sep 17, 2017 at 3:36 PM, Ujjwal Sharma ***@***.***> wrote: I don't think the interfaces would be any specific to our codebase and thus would be open for use in any application making use of the upstream bot library. The shared resources (eg: Github) are specific to our behaviors and thus stay limited to our own codebase. The additional behavior pattern would be added to the core logic of the bot, it is not specific to plotsbot. We should make another issue for that change and document all our discussions regarding it there. I hope I was able to satisfactorily answer you. If not, please feel free to ask again. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ7MOoY0kEkek9OhKIwESYt1qPUikks5sjXTHgaJpZM4OLbPc> .

[ryzokuken]

@jywarren Well, the GitHub variable belongs to the state of behaviors, so that won't change. However, we will do:

1. const Bot = require('chatbot').Bot;
2. const ircClient = require('chatbot-interface-irc');
3. const cliClient = require('chatbot-interface-cli');
4. const Behavior = require('chatbot').Behavior;

or better, couple 1 and 4 with something like import { Bot, Behavior } from 'chatbot'; later.

Almost everything else is related to behaviors, I feel, and should remain in our codebase. Makes sense?

[jywarren]

Agreed with @ryzokuken this is a good step now.

I also wanted to suggest we allow adding behaviors simply by requireing them. This'll further separate behavior code and allow behaviors to be developed as independent modules. What do you think?

[ryzokuken]

@jywarren I don't understand. Aren't we doing that right now? Inside of src/bot.js, we require the core chatbot functionality (src/behaviors/index.js for now, will become an independent module soon, it seems) and require all of our behaviors, which should stay inside of the plotsbot module for now, but yeah, who knows, maybe someday a particular behavior would become big and generalized and complicated enough, we will develop it as a separate module.

[ryzokuken]

So, let's discuss the specifics. What should I name the package? Under what license should it be released? Should it be added as a repository under the publiclab orgranization, or should it be a personal repository?

[jywarren]

Hi, @ryzokuken -- re:

Aren't we doing that right now?

I'd like to propose additionally that we simply require everything in a behaviors directory, without needing an explicit line for each behavior in the code (as we do on this line:

plotsbot/src/bot.js

Line 16 in 29f6198

const heatBehavior = require('./behaviors/heat');

)

Or that we have a configuration file that each person can set for the behaviors they want. This could have a set of defaults.

But this is secondary to the question of the separate generalized bot idea. Let's do a GPLv3 lib, and I'm happy to make a publiclab repository.

I guess I still don't really see why, if all the behaviors and interfaces are modular already, we need a separate bot. Can you answer:

1. Wouldn't plotsbot just be a /configuration/ of the generic bot, and so isn't it already in some sense?
2. Wouldn't we want to provide the behaviors as attaching directly to the generic bot and not underneath plotsbot, or if plotsbot is the generic bot, then we've already done this (and my above question about how to require behaviors is relevant)?
3. Alternatively, if plotsbot is just a configuration, would other instances of the bot copy all of plotsbot in order to make a specific instance of the generic bot, and then change the behaviors that are required in, to customize it?

Thanks!

[ryzokuken]

Exactly my point. The codebase is as modular as it might get already, but the core bot logic and the plotsbot implementations aren't part of separate codebases yet. This gives rise to a ton of problems, because if I needed to say, make another instance, I would either have to fork plotsbot or copy the file.

Instead, if the core logic was maintained as an npm module, everyone could just require the module/package and expect things to work well, in a backwards compatible way.

[jywarren]

OK, that sounds good then. For a name, maybe "multibot", since it works across various interfaces? And would this new repo point at `plotsbot` as an example of how to make a customization of the general bot? If so, great!

…

On Wed, Oct 18, 2017 at 12:46 PM, Ujjwal Sharma ***@***.***> wrote: Exactly my point. The codebase is as modular as it might get already, but the core bot logic and the plotsbot implementations aren't part of separate codebases yet. This gives rise to a ton of problems, because if I needed to say, make another instance, I would either have to fork plotsbot or copy the file. Instead, if the core logic was maintained as an npm module, everyone could just require the module/package and expect things to work well, in a backwards compatible way. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJxbL1LkVYmqZwODOJW7JXqFK5nXVks5stlWCgaJpZM4OLbPc> .

[ryzokuken]

Yeah, it will have to. I mean, plotsbot is always going to be "the implementation". I guess anything you'd like would be fine for the name. Please create the repository if you want it to be created in publiclab organization and I'll add the initial PR.

[jywarren]

Cool, I'll make you an admin!

…

On Wed, Oct 18, 2017 at 12:50 PM, Ujjwal Sharma ***@***.***> wrote: Yeah, it will have to. I mean, plotsbot is always going to be "the implementation". I guess anything you'd like would be fine for the name. Please create the repository if you want it to be created in plotsbot and I'll add the initial PR. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#53 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABfJ7dIVQSp_4Wynvh2Vo6f_UWMynVOks5stlaKgaJpZM4OLbPc> .

[jywarren]

https://github.com/publiclab/multibot !