continuous-integration/drone/push Build was killedDetails
- Converted `Response` objects into `Schema`s.
- Removed the last references to the deprecated `Mapping` object.
- Fixed all errors and warnings in the plugin.
continuous-integration/drone/push Build is passingDetails
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
continuous-integration/drone/push Build is passingDetails
- 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.
Plus, `platypush.schemas.system` has now been split into multiple
submodules to avoid a single-file mega-module with all the system
schemas definitions.
- Support for cloud instances as native entities.
- Using Marshmallow dataclasses+schemas instead of custom `Response`
objects.
- Merge `linode` backend into `linode` plugin.
- Merged together Bluetooth legacy and BLE plugins and scanners.
- Introduced Theengs as a dependency to infer BLE device types and
create sub-entities appropriately.
- Using `BluetoothDevice` and `BluetoothService` entities as the bread
and butter for all the Bluetooth plugin's components.
- Using a shared cache of devices and services between the legacy and
BLE integrations, with merging/coalescing logic included.
- Extended list of discoverable services to include all those officially
supported by the Bluetooth specs.
- Instantiate a separate pool of workers to discover services.
- Refactor of the Bluetooth events - all of them are now instantiated
from a single `BluetoothDevice` object.
The `disable_logging` attribute was only available on events and
responses, and it could only either entirely disable or enable logging
for all the events of a certain type.
The new flag allows more customization by setting the default logging
level used for any message of a certain type (or `None` to disable
logging). This makes it possible to e.g. set some verbose events to
debug level, and the user can see them if they configure the application
in debug mode.
It also delegates the logging logic to the message itself, instead of
having different parts of the application handling their own logic.
Fabio Manganiello
Fabio Manganiello