In progress…

Although Thriot has many-many features there are several features and architectural improvements that are to be done. This page has a list of planned and upcoming tasks. The tasks won’t be necessarily implemented in the order presented here.


Name Short description Category Progress
PostgreSql support for messaging, management and telemetry data As a first step to Linux support it’s essential to provide support for a platform independent data storage that has the required features and performance. The candidate is PostgreSQL. Architecture, Platform independence DONE (development, dev integration, production integration, documentation)
Linux host support on service side using Mono Hosting support on Mono that will make the system run on Linux. The first targets are Ubuntu 14.04 LTS. Architecture, Platform independence DONE. APIs and Services running on Mono under Ubuntu 14, MVC running under ASP.NET 5 + Mono, PgSql running. Documentation for test env done.
Hosting on ASP.NET 5 Host the whole service side on ASP.NET 5 on top of .NET 4.6 (not .net core) Hosting DONE. Development +  Documentation
Linux host support on service side using ASP.NET 5 on Mono Hosting support on ASP.NET 5 on Mono that will make the system run on Linux. The first targets are Ubuntu 14.04 LTS. Architecture, Platform independence DONE: Development +  Documentation
Port the service  from .NET FW to  CoreCLR/CoreFX The service hosting currently requires the .NET Framework on Windows and Mono on Linux. The final target is  .NET CoreCLR/CoreFX on both platforms. Architecture, Platform independence Blocker: Not all external nuget components/packages support CoreCLR yet.
Support on ARM Linux Banana PI or Raspberry PI Architecture, Platform independence
User management features on the website Resend activation email, change password, forgot password Usability DONE (service and UI development, client development, documentation)
Massaging improvements – Track message sender id in DB and message DTOs
– Keep Alive initiation should be moved to the client side
Messaging DONE. Sender Id development and documentation done. Heartbeat function on client side: done.
Reliability improvements for websocket service Ensure to initialize external service inputs while running the service if the initial load fails Reliability
Versioning support for CreateAzureStorage Store the database version when running createazurestorage Configuration  DONE
TLS (HTTPS, WSS) support Provide HTTPS and WSS support for service endpoints to have a secure channel for communication Security  DONE: Windows+Linux services+client, with  Documentation
Queueing support for incoming telemetry data To make the system more scalable add (optional) support for queueing for telemetry data. The incoming telemetry data should be put into a queue, a backend service (even deployed to multiple hosts) should process the messages in the queue. Architecture, Scalability DONE: Implementation for Azure Queue, MsSQL, Pgsql based queue handling, integration, testing, documentation
Implement one or more of the following queues for telemetry data: Eventhub, Servicebus, RabbitMQ, Kafka Based on the queueing support implemented add plugin for the most common queueing solutions Architecture, Scalability DONE: Eventhub

TODO: Servicebus, RabbitMQ, Kafka

Todo: Some documentation

Configuration file based system autoconfiguration at build time Create a configuration file schema and a processor for this that can be used to describe to configuration  (connectionstrings, urls, smtp, etc.) of the target system. The settings will be written to the api an service configuration files at build time. Using this solution the boring manual configuration can be avoided. Configuration DONE: Implementation, examples, documentation
 Plugin handling improvements  Plugins shouldn’t be referenced by the websites and services. They should be loaded from a well-defined folder automatically.  Configuration, Architecture DONE: Development: TODO: documentation changes
Scaling out messaging Messaging currently runs on a single (SQL-based) box. Add support for multiple sharded instances of messaging backend. Architecture, Scalability
Events and triggering Add support for defining rules for incoming telemetry data (above/below threshold for a given time, etc.) and an event sink (REST call, email, etc.). Platform functionality
Throttling service calls Add throttling (configurable at system level and maybe at other levels) for service calls to support QoS for users. Reliability
Massaging improvements 2 Message Unique Id as preparation for MQTT support Messaging
MQTT and/or COAP support Add support for MQTT and/or COAP to provide de facto standard IoT protocols. Architecture, Connectivity
Add generic REST endpoint, EventHub, and Cassandra support for telemetry storage Add generic REST endpoint, EventHub, and Cassandra support for telemetry storage to be able to integrate the system with external services to make Thriot more extensible from the functionality perspective (analytics, etc.) Platform extensibility DONE: Cassandra (and Eventhub done in other task)
Internal service statistics support Add internal performance counters for service calls to be able to provide reports for service usage. Statistics and Reporting