search

SignalK / specification

Signal K is a JSON-based format for storing and sharing marine data from different sources (e.g. nmea 0183, 2000, seatalk, etc)
Other
91 stars 68 forks source link

Handling complex actions and derived values #524

Closed rob42 closed 5 years ago

rob42 commented 5 years ago

See https://github.com/SignalK/freeboard-sk/issues/66#issuecomment-440718641

There are many cases where a key/value change triggers further change. A common case is calculating true wind when apparent changes, or updating route XTE etc when following routes.

While we could add specific functionality to each server implementation there are likely to be endless use cases, which would then be poorly supported across implementations. Any sort of signalk API to manage these will broaden the scope of signalk and make compliant servers difficult to provide.

It makes more sense to create stand-alone programs (call them Bots) that subscribe to the signalk server and perform these updates/actions, rather than being part of the server. That would allow then to be written in any convenient language and added to any server installation. It simplifies the signalk server implementation, and allows wider contributions from the community. The Bots could be made available in an app store, like we do with web-apps.

At the same time we should make a specific decision to limit the scope of the signalk specification to the data model and access/modification/etc of it. eg it maintains and notifies the state of the vessel.

tkurki commented 5 years ago

One way to think about this is that we have a bunch of data, call it "raw" data, and a bunch of "well known" derivation formulas (true wind, XTE etc). The server could "advertise" the formulas as sk paths that it has installed and that are active based on what raw data has been recently(?) available.

If you open a streaming connection for self data you only get the raw data, but you can subscribe additionally/only to also the derived data.

The problem is that some of the calculations are not so simple (like performance figures from polars) and I can't think of a reasonable way to implement Bots in anything but a full blown programming language.

rob42 commented 5 years ago

Bots will mostly need a full programming language, but that may be python, perl, or whatever. they can also be built into the server itself, makes sense for true wind and XTE, since those are 'well known' requirements. But I dont think they should be part of the signalk spec. eg its a signalk server with some built-in bots.

I dont think the signalk server should care if the data is raw or derived. Its job is to store and notify changes to the vessel state. It really doesnt matter if the state changed via sensor, gui, or bot.

rob42 commented 5 years ago

See #543