Suggestion: separate AI framework into separate optional library

[pmonks]

From the roadmap it sounds like future versions will start to introduce some kind of AI framework, something that I'm sure will be valuable for many use cases that leverage SJC.

However, I'm also confident that it will not be valuable for all use cases that leverage SJC, so I'd prefer to see this functionality separated out into a separate, optional library, so that consumers who don't need these capabilities aren't forced to bloat their own bots with unused code.

In many respects this is just suggesting that the general design pattern that already exists in the Symphony Java ecosystem (i.e. decomposition of client side functionality into separately consumable units) is applied to this functionality as well - there are already multiple independently consumable Java libraries:

• the swagger generated API layer
• the "value add" services layer
• the MessageMLv2 parser

[ftbb]

We will be discussing this and more during the SJC Design meetup.

In general we need to create the scaffolding for adaptability of key capabilities. With this said, there should always be a reference implementation (default).

AI Framework (pipeline) is about filtering conversations, mapping commands to actions which return data back into the conversation. There are additional layers to this simple pipeline like maintaining context of a conversation in order to provide some logical interactions. The entire framework can be externalized and basic interfaces added to SJC to support implementations.

Again, more to discuss...

[ftbb]

Going to close this as, I'm rethinking it.