Messages can be quite big and verbose, and they can anyway be subscribed
over Websockets.
Full dumps are anyway enabled when Platypush is started in verbose mode.
This commit replaces the dumps on INFO level with a quick summary
containing the message ID, request/event type and response time.
- `stop_conversation_on_speech_match` should default to True.
- `render_response` should also handle conversation follow-ups, set the
follow-up to True if the response ends with a question mark and the
value of `with_follow_on_turn` is not set,
- Don't render responses if a `tts_plugin` is not set.
`assistant` contains the assistant plugin object that triggered the
event, but you can't create event hook conditions on attributes that are
plugins.
The event should also store a `plugin` attribute which contains the
unique plugin name, so hooks like these can be built:
```
from platypush import hook
from platypush.events.assistant import ConversationStartEvent
@when(ConversationStartEvent, plugin="assistant.google")
def on_google_conversation_start():
...
```
It wouldn't be possible to construct a hook condition like the one above
on the plugin object reported on the `assistant` attribute.
The Fit API has (unfortunately) been deprecated by Google with no
alternatives - the new Health Connect API is only available on Android
devices.
Other Google APIs don't seem to be affected by the refresh token issue
either, so this should hopefully close that issue too.
Closes: #372
- Converted `Response` objects into `Schema`s.
- Removed the last references to the deprecated `Mapping` object.
- Fixed all errors and warnings in the plugin.
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.