To teach David how to handle different ways of understand "human messages", is needed to implement a generic way to receive data and handle it to generate a a useful conversation model.

The main idea is to support API payloads of any platforms. By example:

For input in Watson's API payload format:

POST http://localhost:5005/dialog?_if=watson

If the input format isn't explicitly informed, maybe we can build a component that tries to resolve the format.

Also maybe we can implement support to output format, but only if will be needed.

Now is needed to create an instance of each adapter for use of him.
My suggestion is to use them as static classes that will be best when we are working with asynchrony.

With issue #48, we will able to read in some formats.

And with issue #49, we will able to read JSON files.

The objective of this issue is to create a reader to read Watson's JSON file.

This is from #68

It is needed to configure and implement integration tests between:

• David components
• David intern APIs
• David external APIs (like Rasa, IBM Watson and so on)

To show how technically good is this project, add the codeclimate is needed.

@ralphg6 as owner to add it is needed:

1. Sign up into codeclimate (using GitHub account if you want)
2. Add David project to codeclimate
3. After the build, just click in Repo Settings and copy the badge URL

Now the project is classified as A it is the best rank of codeclimate! congratulations!!
I updated my fork with this badge if you want to see it:
https://github.com/arthurTemporim/david

This issue is a child of #10

Each component has it's own specific configurations, then is needed that the config file suport.

To help project management and avoid duplicated work, a project board should be created.

After #34, we must include components's lifecycle in the documentation.

The issue #40 refers to the implementation of the engine.

In issue #19, we created a layer to adapt the dialog API for the desired format.

Now we able to build adapters for any formats compatible with Message object.

https://github.com/ralphg6/david/blob/bfb535c21f9bf7720e58d99653334972958e03f9/david/typing/message.py#L11

To build a new adapter is needs to implement the class Adapter.

https://github.com/ralphg6/david/blob/bfb535c21f9bf7720e58d99653334972958e03f9/david/adapters/adapter.py#L7-L21

As I built the MessageAdapter:

https://github.com/ralphg6/david/blob/bfb535c21f9bf7720e58d99653334972958e03f9/david/adapters/adapter.py#L24-L36

This component must be a Dialogue Component, and your operation must be by an API call to Rasa Core.

With issue #48, we will able to read in some formats.

The objective of this issue is to create a reader to read any JSON file.

This component must be a Dialogue Component, and your operation must reproduce the operation of the Watson Conversation service.

To improve code maintainability and make the project learning curve easier, code documentation should be configurated and described.

The idea is include on CLI and config file a option that permit bypass some errors during training data reading.

Examples:

CLI:

david --ignore-read-errors

or config.yaml

ignore-read-errors: true

Other idea is create some levels for bypass...

This component must be a Dialogue Component, and your operation must be by an API call to Watson Conversation.

In issue #19, we created a layer to adapt the dialog API for the desired format.

For more details view #37.

To continue to document the project, we have that adjust the main Makefile and reorganize doc files to correct folders.

Issue from #68

It is needed to configure and implement load tests to David.

Tasks:

• Define the tool to be used
• Configure load tests
• Implement at leas one load test

The main idea is to use Swagger.

We too can create a playground for demonstrations.

The README.md is the face of the project, so relevant information and descriptions is important to engage community members to use and contribute to this project. This issue aims to improve this project README.md.

This is a part of #16

The objective is to segregate functionalities in layers.

• Complex expressions
• Context Variables
• Entities
• Other expressions in SPEL

In issue #19, we created a layer to adapt the dialog API for the desired format.

For more details view #37.

The changes must become in:
https://github.com/ralphg6/david/blob/bfb535c21f9bf7720e58d99653334972958e03f9/david/registry.py#L13-L19

In issue #19, we created a layer to adapt the dialog API for the desired format.

For more details view #37.

The PR #21 added support to Black but requirements file not updated ...

And we have document his usage.

The idea is to modularize the training data reading to we will able to read in the format of many platforms.

It is important to highlight that some components of NLU or Dialogue can need a specific reader.

For example, to use Watson Alternative Dialogue components will need to use a reader for Watson's format.

This issue aims to configure a unit tests tool.

Tasks:

• Define a test tool (probably pytest)
• Configure it locally
• Add tests to CI
• Add badge of project coverage
• Create the first test of the project

Is important too:

• Define how to make integration tests (very important to components usage). Moved to #76
• Define how to make stress tests
• Define how to make load tests. Moved to #77

All nlu legacy code must go to SimpleNLU component.

Migrate http serve start to command:

david run

I think that we will able to configure two ways.

By config file and by CLI arguments. Being that CLI args prevail over the config file.

The configs must be easily available in all the project code.