Multiadapter support

[gunthercox]

This ticket introduces the road map for the next set of major changes to ChatterBot. Multiadapter support is the addition of the ability for ChatterBot instances to be configured with any number of each type of adapter.

• Storage adapters
• Logic adapters
• Input/Output (IO) adapters

Storage Adapters

Multi adapter support for storage adapters means that it will be possible for ChatterBot to be connected to multiple storage backends. The advantage that this will provide is the the ability for a ChatterBot instance to derive responses from multiple sources. In some cases these databases may be dynamically updated independently of the current ChatterBot instance. An example where this configuration would be useful is demonstrated in cases such as the twitter storage adapter. A chat bot configured with a local database adapter and the twitter storage adapter would be able to join results from both sources to produce a response, increasing the diversity of the knowledge base.

The upgrade to a multi-storage adapter setup will require the following changes to be implemented:

• It should be possible to individually set which databases are read-only.

Logic adapters

Setting multiple logic adapters will make it possible to produce more advanced responses while keeping each logic algorithm modular.

The upgrade to a multi-logic adapter setup will require the following changes to be implemented:

1. Logic adapters will need to have a method for determining the confidence that the result produced by each adapter is correct. This value should be a percentage represented by a value between 0 to 1. In the case of existing adapters such as closest_match, this value could be determined by the percentage that the closest matching statement matches the input statement. In other adapters, the resulting value could simply return a 1 or a 0 depending on if a specific input matching a given requirement is detected.
2. It will be important to watch out for cases where one logic adapter's confidence algorithm has an incorrectly increased probability of resulting in a higher confidence than another algorithm's. This may be handled best by allowing for the manual specification of scaling factors.
3. Tie breaking will be accomplished via an order of precedence determined by the order in which each logic adapter is listed. In the case of a tie in resulting confidence values, the adapter that was listed first will be given the highest priority and thus, it's result will be returned.

IO adapters

Multi adapter support for IO adapters entails that a ChatterBot instance will be able to receive input from multiple sources. There are many cases where this would be useful. A simple example is a setup where a single bot is required to communicate with users through two different endpoints (such as google hangouts and an IRC channel (or multiple IRC channels)).

[LucasZielke]

In the case of the multiple logics wouldnt this require it to completely restructure its internal "thoughts" after every input? or at least after every input, would have to recognize that there has been a change added/delete in the linked databases?

[gunthercox]

@LucasZielke What brings you to that conclusion?

[gunthercox]

• Just a note, although multi-logic adapter support has been added, it is not currently using the weighting based on adapter order as described in the initial ticket. Right now it will simply select the first, highest confidence result that it can generate.

[gunthercox]

I had a chance to think about the implementation for multiple io adapters a bit more yesterday. When retrieving input from multiple sources, the response should be returned to the adapter that the input came from. So for a hypothetical scenario with multiple io adapters:

Process input	Process response	Process response
Input received from email adapter	-->	Return email
Input from terminal)	-->	Reply in terminal

[gunthercox]

Closing this ticket off because the multi-adapter has been created for logic adapters. I am not planning on adding support for multiple databases because the amount of time it would take to query multiple large databases causes more problems than it fixes in the long run. I am also re-thinking having multiple IO adapters as it adds a lot of complexity without many advantages. For many cases it makes more sense to just create multiple bot instances when more than one input and output method is needed.