break out chatter bot into a module

[yocontra]

I think the actual logic for generating responses should be it's own module. The interface should be similar to node-markov, jsmegahal, etc. in terms of seeding/getting responses

[spion]

Ideally this is true, however I don't want the implicit guarantees that come with a separate module. At this point triplie is more of a research project rather than a library for constructing chatbots - I want to have the freedom to tear down everything then rebuild it in a completely different way.

Note: the interface cannot be the same. For example, triplie also expects timestamps for its data - meaning that neither node-markov nor the jsmegahal interface will do. What I would need is for the interface to support extendible data, maybe via a JSON object, because I don't know all the possible input data that I'd like the bot to know (things like person, chat location may also prove useful provided I figure out a way to incorporate it)

Some other interesting data that isn't available via IRC - user deliberation (e.g. the pauses that they've made during their writing)

[yocontra]

@spion A similar interface though in terms of adding messages, even it is like .add({date, message, author}) or something would be great. I think its a great disservice not to publish it as a module for others to use. The ecosystem for making chat bots in node is not ideal right now.

[spion]

I feel it would be more of a disservice to publish something that I intend to break often and not really support. There are a lot of decisions that will have to be made that I'm simply not comfortable with making.

Consider the storage system for example. Should I settle on SQLite? Should I make it pluggable? If pluggable, then what interface should the storage system support? Thats a pretty hard question to answer. Ideally you would want a pluggable storage system, but if the data model changes all the time, and right now performance dictates that a lot of work is done in SQL for example. Could the bot be decoupled from its storage? I have no idea.

[yocontra]

@spion Not comfortable publishing, got it. Hopefully sometime in the future you will feel comfortable partaking in the OSS/npm stuff

[spion]

I'd leave the issue open. If I come up with a satisfying way to decouple the storage mechanism, I think it may become viable. Will have to go through all the rest of the bot though, just in case. Also figure out if the algorithm is stable enough to write some unit tests. So a to-do list, before this can be done:

• stable data model, or at least a stable extensible interface for pluggable storage, or decide to settle on always using SQL(ite)
• Write unit tests

Regarding point no.1 I'd like to know - would you use the bot as a separate module if its storage is tied to SQLite?

[spion]

@Contra I'd appreciate if you keep the reasonable tone you used before. However if you honestly believe what you wrote, I hope that the stuff listed here migth change your mind.

I like the suggestion, and the reason I'm uncomfortable splitting the engine from the bot was clearly stated. Lets work on eliminating that reason first.

[jmcbee]

:+1: We would love this.