If there's a good use-case for overriding `Event._matches_condition`
with a logic that also parses the event arguments, then those arguments
should be accessed directly from the event object, not from the match
result.
Initializing `EventMatchResult` with the arguments from the event means
that, if `EventMatchResult.parsed_args` are populated with custom
extracted arguments, then the upstream event arguments will also be
modified.
If the event is matched against multiple conditions, this will result in
the extracted tokens getting modified by each `matches_condition`
iteration.
The assistant object now runs in its own thread and leverages an
external `SpeechProcessor` that uses two threads to scan for both
intents and speech in parallel on audio frames.
`AssistantEvent.assistant` is now modelled as an opaque object that
behaves the following way:
- The underlying plugin name is saved under `event.args['_assistant']`.
- `event.assistant` is a property that returns the assistant instance
via `get_plugin`.
- `event.assistant` is reported as a string (plugin qualified name) upon
event dump.
This allows event hooks to easily use `event.assistant` to interact with
the underlying assistant and easily modify the conversation flow, while
event hook conditions can still be easily modelled as equality
operations between strings.
1. `chat.telegram` -> `telegram` plugin.
2. Merged `backend.chat.telegram` logic into `telegram` plugin.
3. Rewritten the architecture of the integration to adapt to the new
asyncio API introduced in the latest versions of telegram-bot-api.
Closes: #349
- Fixed regression introduced by incorrect format string in `exec`.
- LINT for the `procedure` module.
- Apply `Message.Encoder` when dumping values from the context.
- Merged `trello` plugin and backend into a single plugin.
- Removed legacy `Response` objects, replaced with data classes and
schemas.
- Fixed the Websocket connection flow to reflect the new authentication
protocol.
Closes: #307
- The following logging namespaces are now used, to make it easier to
filter only log lines related to the logged application message:
- `platypush:events`
- `platypush:requests`
- `platypush:responses`
- Those messages are always logged as JSON, with no prefixes nor
suffixes.
- Requests are always logged when executed - no more delegation to the
upstream backend.
- Responses are always logged when fully populated (including `id`,
`origin`, `target` etc.), instead of being logged when still partially
populated. This makes it particularly easy to link request/response
IDs directly from the logs.
The Tensorflow module may take a few seconds to load the first time and
slow down the first scan of the plugins.
All the Tensorflow imports should therefore be placed close to where
they are used instead of being defined at the top of the module.