The everpl from s-kostyuk

Implement aspects

Implements a set of aspects or middlewares that will:

control permission checking;
perform logging;
control DB Session lifecycle (i.e. opening and closing of transactions)

Blocked by #61

API versioning

Introduce REST API versioning, stabilize basic API, release v1 of API.

REST API caching subsystem

Implement a module for caching of API responses.

It must to analyze 'last_updated' field of cached resourses, calculate ETags (or generate some other value that can be used as ETag) and set corresponding HTTP headers

Filtering for Things

Implement a support of filtering for Things (items in /things/ REST API endpoint).

Parameter-based filtering is proposed. To filter all things by their placement, the following request will be able to be used:

curl --request GET \
  --url 'http://dpl_host:dpl_port/things/?placement=R1' \
  --header 'Authorization: your_auth_token_here'

In support of filtering approach, based on query parameters, see the following descriptions and mentions:

in GitHub documentation
in "Web API Design" e-book
on Hackernoon: article
and also here and here

Refactor: Add domain_id to all classes of object model

For now not all classes from object model have an identifier as a property. Objects of Placement class store their identifiers "placement_id" property, objects of Thing - in "metadata" dictionary as a value of "id" key and Connections don't have identifiers at all.

So, it's time to make some consistency in structure of all object model classes and to add an "domain_id" property

Introduce DB for configuration of Things, Placements and so on

Introduce a database for storing of configurations of all Things in the system. Replace current config-file configurations of Things with DB alternatives

So, the subtasks:

New API resource for sending commands to Actuators

Create a new REST API resource for sending of commands instead of the current '/messages/' endpoint
Mark '/messages/' endpoint as deprecated
Document the new resource and its behavior

Update storage of core configurations

Implement some new class which will store all core configurations
Add an ability to load configuration from an .yaml file
Add an ability to start without an existing config file with default settings
Add an ability to temporary override some settings on start

Deprecate ApiGateway

Eliminate the need in a central ApiGateway for managing of all request to the system.

Blocked by:

#40 - Separate RestApi provider into separate views
#38 - Deprecate UserManager
#39 - Deprecate AuthManager

Introduce Capabilities in REST API and other client views

Related to #29

Refactor: Implement classic architecture with Repos and Services

Looks like we need to switch from current home-brew architecture to almost classical architecture with separate Repositories and Services.

For now the functionality of Services is entrusted to such entity as "ApiGateway". It control almost everything related to the of processing requests coming into different API implementations (like RestApi implementation). There is no separation of responsibilities between services based on functionality and a set of related objects.

The functionality of Repositories is entrusted to PlacementManager and BindingManager. Those two managers store and control access to Placements (the first one), Connections and Things (second one). Also they perform a small subset of functions usually entrusted to services like enabling and disabling of Things.

The last aspect to consider is a possibility to switch to Redis, SQLite or other lightweight databases for storing of persistent data (like settings of Things and Connections, like a set of Placements and Users and so on).

Considering all mentioned information, to facilitate further development of the platform, the following decision was made:

create a set of abstract Repositories for each entity in the system;
create a set of Repository implementations that will use SQLite to store persistent data;
create a set of Repository implementations that will store data about Things and Connections in memory;
implement DTOs and DTO Builder for Things, Connections and Placements;
prepare declarations of interfaces for Services;
create a set of corresponding Services for managing Things, Connections and Placements;
replace current Managers with Services;
prepare everything needed to add user control policies and User management in the next (v0.3) release

Documentation for v0.4

Prepare proper documentation for:

REST API interface
concepts of Platform, Connection and Thing
everpl start-up process
a general structure of everpl and its core classes

New format of Things

Separate all functions of Things to the separate interfaces ("capabilities") like:

IState
IActuator
IValue
IBinary
IThreshold
IColor
IIntensity
IPlaylist

and so on

Simpify first start process

Prepare package
Add command-line options
Set path to config

Fix CORS preflight handling

Add handling of OPTIONS requests for things and placements endpoints. Otherwise preflight will fail and it will be unable to read any data from server from host another than the platform host itself

Choose placement of version constant

Choose one of the ways of version single-sourcing, either described in this document or an own one: https://packaging.python.org/guides/single-sourcing-package-version/

Review config format

Review a structure of platform's configuration, their placement in file system and file format

Tests for v0.1 functionality

Add missing unit tests for different classes that was present in v0.1 of this application

DLNA Integration

This task will be a quite hard. The list of available libraries is very limited. Maybe the best one is Cling written in Java. It's used by BubbleUPnP and other good applications. The second one is libupnp written in C. There are also Intel Leyna, Platinum UPnP and dlnap.

But. There is only one ready-made Python implementation - Coherence. It's abandoned now. And wasn't updated for a very long time.

Placement management in REST API

Description to be filled

Implement everpl streaming API

Implement Zeroconf announcement

Announce presense of adpl server in local network via zeroconf (avahi)

Discovery modules

Implement basic support of thing discovery mechanism. Create base classes and factories, create example platform-specific implementation

dotcat_home integration

Description to be filled

Choose some AOP framework

Choose some AOP framework to be able to:

perform centralized logging of Service calls;
open and close DB transactions;
check if an access to the requested resource or actions is allowed (permission control)

So, some sort of middleware is needed to perform such tasks prettily

Support for python versions < 3.5

If you need a support of python versions older than 3.5 - please, endorse this issue.

Event subsystem

Implement a sort of event bus which will gather all changes and other events of the system. And, in future, will be able to send events to corresponding handlers, notify client devices and save events to DB.

User management in REST API

Description to be filled

Introduce "safe" mode

Add a possibility to start the platform in the "safe" mode.

In the safe mode all optional components of the system are disabled, i.e. all integrations, all features like push notifications and everything else that can be disabled. The only thing that will left working is a user interface with an ability to enable / disable components and integrations, edit some settings and to do anything else to rescue the system

Thing creation in REST API

Description to be filled

New format of error messages

Update all error messages to the new format as described in documentation.

LocalDiscovery: Graceful degradation on missing dependency

dependencies for disabled components should not be imported at all;
missing dependency for an optional component should not (??) cause a platform shutdown
(if only such shutdown isn't desired by user).

Deprecate AuthManager

Create a new Service which will manage user authentication, access token management, access control and policies

UPD:

OK, there are some things to do:

define an entity that will represent access tokens;
define a repository of access tokens;
create a service for auth and token management

Deprecate UserManager

Replace a UserManager class with a corresponding UserRepository -- UserService combination

Implementation of Interceptor pattern with attachable Aspects

As was stated in #61 (comment), Interceptor pattern will be used to implement a support of Aspects in everpl.

So, here is the task:

Create a class of objects that will be used for dynamic weaving of existing objects (instances), will mimic an interface of a weaved object, intercept all calls to the public methods (excluding properties) and will call aspects before, after or instead of the original (wrapped) methods.

Make ThingService.execute method non-blocking

For now all commands to the Actuators are sent synchronously, in a blocking manner. As result, the whole platform (i.e. updates of a Thing state, HTTP request handling and so on) stuck until the execution of the requested command will be finished. It's not good and must to be fixed

Implement Authentication aspect (in a form of context manager)

Implement an Aspect that will control Authorization in the system. I.e. will check if the current user is able to (is authorized to) execute a requested action.

Use Python's Context Managers and a concept of Ambient Context for passing of authentication tokens, use Interceptor pattern as an implementation detail for controlling of calls to Services.

Blocked by #63

MPD platform implementation

Implement Transactional aspect

Implement an Aspect that will control opening and closing of transactions on each call to the methods of Services or of some other wrapped objects

Blocked by #63

Finalize ThingService implementation

For now ThingService lacks implementation of several important methods:

It's needed to finalize their signatures and implement them

OAuth 2 Support

The current custom-made token-based authorization scheme is quite similar to the same in OAuth. Current custom protocol is based on revocable access tokens that are unique to one instance of client application and one user of it. In near future it is planned to support different access scopes that restricts an availability to perform some requests and actions in the system.

But, if we'll look closely, OAuth protocol supports this functions already, by design. And provides some other neat features in addition.

So, in future (maybe, quite near future) it's likely that OAuth protocol support will be implemented in platform. And in somewhat distant future it's likely that OAuth protocol will replace a current custom one.

State changed events for Actuators

Implement a some sort of events from C#, add events like 'on_state_changed' to the base implementation of Actuator

Event history module

Finalize basic Capabilities

Finalize the list of basic Capabilities such as On/Off, Open/Closed, Is Active and so on
Finalize the naming scheme of Capabilities - #86
Document all basic Capabilities - #89
Change Thing implementations according to the new Capabilities - #85
Prepare everything needed to be able to list all Capabilities supported by a Thing in client views - #87

Separate RestApi provider into separate views (subapps)

For now a single class called RestApi contains an implementation of all request handling logic. It is connected directly to a god object called ApiGateway and uses its interface to process requests, return and alter data in the system.

The better approach is to have several views, when each of them will use exactly one Service class for its needs and will be responsible exactly for one set of resources like all /things/ or all /placements/

New Users subsystem

Implement a new subsystem which will store a list of registered users and will allow to control their access to system's resources in the future

Implement the new User class
Declare UserRepository interface
Declare UserService interface
Add ORM bindings for User class
Implement ORM-backed UserRepository
Implement UserService
Implement UserDto
Attach UserService to the REST API

Move specific integrations out of the main 'dpl' package to their own packages
Fix package import and registration logic corresponding to the new structure

s-kostyuk / everpl Goto Github PK

everpl's People

Watchers

Forkers

everpl's Issues

Recommend Projects

Recommend Topics

Recommend Org