v0.3: Some new stuff

What changed for end-user?

• marked /messages/ REST API endpoint as deprecated;
• added a new /execute REST API endpoint for Things (#81);
• introduced the concept of Capabilities for Things (#88);
• added an optional Zeroconf announcement support (#93);
• changed the naming format for packages with integrations (#75);
• doc available at http://everpl.readthedocs.io/en/v0.3.0/.

Everything else is a bunch of under-the-hood changes.

Full Changelog:

Core:

• nothing changed.

Architecture:

• added aspects for access control, DB session management and other similar stuff (#63, #64, #65).

Authorization:

• BREAKING: reworked authorization and access control logic (#59, #76);
• introduced new classes: User and Session;
• introduced UserService, SessionService and corresponding repositories;
• introduced an AuthService #59.

Placements:

• kept unchanged.

Thing subsystem:

• introduced Capabilities;
• reworked 'build_dto' implementation for Thing instances to support new Capabilities (#87);
• BREAKING: changed the signature of 'select' methods for ThingRepository (2a3e1f7);
• BREAKING: removed a 'state' property from the base Thing class;
• BREAKING: moved abstract base implementations of Things from dpl.things to dpl.integrations package;
• BREAKING: changed the naming format for packages with integrations (#75);
• BREAKING: moved Dummy integration sample and a corresponding tests to the separate package.

REST API:

• implemented an '/execute' endpoint for Things (#81);
• separated REST API provider code into different subapps by resources they control (#78);
• BREAKING: Removed API Gateway and a legacy REST API implementation (#80).

Other components:

• introduced LocalDiscovery component (#93);
• BREAKING: Fixed inconsistency with 'select' methods of Repos (6bd353a);
• BREAKING: renamed SQLAlchemy-related SessionManager to the DbSessionManager (a655e7a).

v0.2: Rethinking legacy

What changed for end-user?

• changed configuration format;
• documented REST API resources and behavior;
• prepared a pip package;
• added a bunch of new dependencies;
• deprecated some fields in the REST API.

Everything else is a bunch of under-the-hood changes.

Full Changelog:

Core:

• allowed to
• changed a path to the configuration files: from now the are stored in the user's configuration directory (like ~/.config/upport;
• reviewed configuration format: from now only platform-related configuration is stored in the config file;
• changed configuration file format from a bunch of JSON files to a single YAML file;
• added an SQLite database for storage of persistent data like settings of Things and parameters of Placements;
• added a script for migration from v0.1 config files to the new configuration;
• initial support of command-line arguments (a list of the arguments is very likely to be changed in future).

Architecture:

• initiated another refactoring and a shift to the onion application architecture;
• created a bunch or repositories and services instead of PlacementManager and BindingManager (#32);
• added domain_id field to all entities in the system.

Authorization:

• nothing changed for now; major changes are coming in v0.3 release.

Placements:

• renamed placement_id a domain_id field for Placement objects;
• created a DTO object type for Placements;
• declared an abstract PlacementRepository interface;
• implemented PlacementRepository interface with underlying persistent storage (located in the dpl.repo_imps.sql_alchemy package) and in-memory storage (located in the dpl.repo_imps.in_memory package);
• declared an abstract PlacementService interface;
• implemented PlacementService interface with an ability to view, add, remove and modify Placements;

Thing subsystem:

• moved an domain_id value from Thing's metadata dictionary to the own property;
• added an is_enabled property;
• created two new classes to store settings of Connections and Things: ConnectionSettings and ThingSettings;
• declared interfaces of ConnectionSettingsRepository and ThingSettingsRepository;
• implemented ConnectionSettingsRepository and ThingSettingsRepository with underlying persistent storage;
• declared interfaces of ConnectionRepository and ThingRepository;
• implemented ConnectionRepository and ThingRepository with in-memory object storage;
• declared interface for and implemented a service for managing of Things: ThingService;
• for now Thing addition is unavailable in ThingService;
• ConnectionService will be implemented in the next release;
• created separate bootstrappers for Things and Connections - objects which will create new instances of Thing and Connection and add them to the corresponding repositories.

REST API:

• deprecated description and image fields for Placements resource;
• deprecated description field for Things resource;
• documented current REST API state;
• implemented error handling and added a set of human-friendly error messages;
• implemented basic CORS support.

v0.1: The new start

The first release of ADPL.

Comparing to the dotcat_platform, the following changes were made:

Core

• the whole system was rewritten from scratch
• changed configuration format
• changed initialization process
• changed project structure

Authorization

• introduced Authorization subsystem
• added new classes like 'User' and 'AuthManager'
• added a concept of authorization token (one for each client device or application)

Placements

• added corresponding 'Placement' class in replacement to simple dictionaries
• renamed 'description' field to 'friendly_name' field
• renamed 'image' field to 'image_url' field

Thing subsystem

• introduced a concept of 'Platform'
• each Platform provides a set of platform-specific implementations of abstract Connections and Things, for example MPD Platform can provide an implementation of Player and MpdClientConnection, Hue Platform can provide an implementation of Lighting, DimmableLighting and RGBLighting and so on
• platforms can be enabled independently
• if platform is disabled or can't be imported (for example, for non-installed dependency), all corresponding Thing items will be temporary disabled too

API

• introduced a concept of ApiGateway
• implemented REST API using aiohttp library

REST API

• REST API is mostly compatible with v0.4-dev.1 of dotcat_platform
• access to the most of API endpoints is protected with an access token
• access token can be fetched by a registered user at '/auth' endpoint
• fully-compatible REST API implementation is placed in 'compatibility' branch
• in 'compatibility' branch authorization subsystem and token-based resource protection can be disabled on start
• more info: https://github.com/s-kostyuk/adpl/wiki/API-home-page