FROST-Server 2.0

[hylkevds]

You may have noticed the develop-2.0 branch and wondered which changes are big enough to warrant a major version increase. Or you may not have noticed, but might still be wondering what the near future of FROST holds. You could of course read the Changelog, but that is a somewhat minimalist list of changes. So here is a bit more detail.

Plugins Everywhere

Many things that are hard-coded in the 1.x branch of FROST-Server are now defined using plugins. This greatly increases flexibility, both for future versions of the SensorThings API standard and for custom extensions. Functionality that is now defined as a plugin includes:

• the Data Model
• Version End points (/v1.0, /v1.1)
• Result Formats

Data Model Plugins

The entire data model served by a FROST-Server instance is now defined in plugins. A plugin can define a new data model, or modify the data model of another plugin. The SensorThings API data model is defined in the CoreModel plugin. The MultiDatastream and Actuation plugins modify this data model to add new entity types and relations.

Version Endpoints

Version End points, or base urls like /v1.0 and /v1.1, are also defined by plugins. The /v1.0 and /v1.1 end points are defined by the CoreModel plugin, as defined in the SensorThings API standard. The (experimental) OData plugin adds ODATA_4.0 and ODATA_4.01 end points that behave according to the OData standard, version 4.0 and 4.01 respectively.

Result Formats

Result Formats were already defined in plugins, but the abstraction has been improved. The plugin can now also specify for which versions (end points) it is relevant.

ID types Per EntityType

In FROST-Server 1.x it was possible to use Numeric or String (UUID) primary keys in the database, but the type had to be the same for all tables. In FROST-Server 2.x the primary key type can be set different for each entity type. This means you can have Things with UUIDs as primary key, but have Longs for all other tables. Of course, changing the settings means you have to re-generate the database.

Flowing Data

In FROST-Server 1.x requested data was first completely loaded from the database, then serialised, and finally send to the client. This means that for large result sets, with deep expands, it can take a long time before the user received any data. It also means all the data has to be held in memory. In FROST-Server 2.x data starts streaming to the client as soon as it is read from the database. This means fewer timeouts and much less memory use.

Upgrade Compatibility?

Upgrading from the latest version of 1.x to the new 2.x should work without any problems. Any old configuration settings that changed will be used to set the new versions of those settings. Of course, make sure you have backups, and test on a development instance first.

When?

The FROST-Server 2.x branch is getting quite stable, especially the core SensorThings API parts. At this stage would help a lot if people could test it!

[rhzg]

What about compatibility between versions, like upgrade from FROST Server 1 to version 2 with an existing data set?

[hylkevds]

Good point! I've updated the post.