This "issue" is based on a conversation started on the Slack plugin channel while discussing ways to implement plugins. As we were exploring use cases for the plugin API, a fundamental question was raised about what should and what should not be part of the "SignalK specification." This issue is for developers to discuss this:
If I were to create a plugin for the SignalK server that is a maintenance management system, I could imagine the need for entities like:
Generic definitions of items that might need maintenance (e.g. a Caterpillar 3506E diesel engine, Westerbeke 20BEDA Generator, etc.)
Generic items that define the maintenance items that need to be done (e.g. oil change, filter change, Heat exchanger cleaning, etc.)
Maintenance schedule on how often each item from (2) needs to be done.
The above items might be shared by the community in some fashion, as everyone who has the same device will need to perform the same maintenance. In addition to these, an individual vessel would need:
A list of items from (1) that are on my personal boat
Maintenance history in the form of a list of maintenance items from (2) that indicates when is the last time I performed a specific item
Any other entities that might help with the process of alerting when items are due and/or organizing maintenance history into usable groups.
My original thought on implementation was a fairly traditional approach: the above entities would be stored in some database (SQLLite perhaps), and I could use the SignalK feed, combined with (5) to predict and indicate when a maintenance item is due to be performed (e.g. 100 hours has now passed on generator engine, so change the oil and filters). That need may be communicated in the form of a SignalK alarm notification, or it may not. A UI for this would consist of web pages for CRUD operations on all of the above items, where the web page communicates directly with the backend plugin RESTfuly using non-SignalK Json objects. Let's call this a "minimal SignalK extension" plugin model. There is a lot of information being stored, but the amount of new SignalK data being generated is small to none. It may be a heavy consumer of SignalK data, but the only new SignalK data it may generate is "its time to do maintenance on X" notifications.
HOWEVER - discussions revealed that there is another approach: some or perhaps all of the entities above could in fact be SignalK data. There would be no need for a web app to communicate directly with its corresponding plugin using some app specific protocol to get, for example, "a list of all maintenance definitions needed on the engine." Instead, it would simply request some high level SignalK path that encompasses that list of maintenance items, and using PUT, those items could perform updates, giving you the CRU of CRUD. The only thing missing would be supporting the http DELETE operation to get full CRUD (though I suppose you could fake that with a PUT of some app specific "delete" operation.)
Would there be a problem with having potentially hundreds or thousands of items as part of the SignalK model (some of those those data points would be the complete history of a specific maintenance item). If so, where would you draw the line, if anywhere? As another example, a "tide prediction" plugin I have already written takes a depth data sample once every 5 minutes, and it organizes those samples into different "locations" to support anchoring at different areas. Should the locations be part of the SignalK model? How about the individual samples? If they all were, there really would be no reason for any plugin UI to have to communicate directly with its plugin using any type of protocol other than the "official SignalK api", which would be extended to support full CRUD semantics on certain paths.
Of course, how persistence is implemented is still a question up in the air - we've talked SQLite, NoSQL, etc. The plugin's persistence model may still be SQLite on the backend. This discussion is really about how the entity data get communicated with a UI. How should plugin developers approach things?
I am interested in the development community's thoughts. Is the vision for SignalK to have EVERYTHING that may be related to the boat and its operation be SignalK, including the care and feeding of the vessel? Or, should there be a more refined view of what is and what is not something that is valuable to be part of the SignalK stream (e.g. limit it to the daily operations).
This "issue" is based on a conversation started on the Slack plugin channel while discussing ways to implement plugins. As we were exploring use cases for the plugin API, a fundamental question was raised about what should and what should not be part of the "SignalK specification." This issue is for developers to discuss this:
If I were to create a plugin for the SignalK server that is a maintenance management system, I could imagine the need for entities like:
Generic definitions of items that might need maintenance (e.g. a Caterpillar 3506E diesel engine, Westerbeke 20BEDA Generator, etc.)
Generic items that define the maintenance items that need to be done (e.g. oil change, filter change, Heat exchanger cleaning, etc.)
Maintenance schedule on how often each item from (2) needs to be done.
The above items might be shared by the community in some fashion, as everyone who has the same device will need to perform the same maintenance. In addition to these, an individual vessel would need:
A list of items from (1) that are on my personal boat
Maintenance history in the form of a list of maintenance items from (2) that indicates when is the last time I performed a specific item
Any other entities that might help with the process of alerting when items are due and/or organizing maintenance history into usable groups.
My original thought on implementation was a fairly traditional approach: the above entities would be stored in some database (SQLLite perhaps), and I could use the SignalK feed, combined with (5) to predict and indicate when a maintenance item is due to be performed (e.g. 100 hours has now passed on generator engine, so change the oil and filters). That need may be communicated in the form of a SignalK alarm notification, or it may not. A UI for this would consist of web pages for CRUD operations on all of the above items, where the web page communicates directly with the backend plugin RESTfuly using non-SignalK Json objects. Let's call this a "minimal SignalK extension" plugin model. There is a lot of information being stored, but the amount of new SignalK data being generated is small to none. It may be a heavy consumer of SignalK data, but the only new SignalK data it may generate is "its time to do maintenance on X" notifications.
HOWEVER - discussions revealed that there is another approach: some or perhaps all of the entities above could in fact be SignalK data. There would be no need for a web app to communicate directly with its corresponding plugin using some app specific protocol to get, for example, "a list of all maintenance definitions needed on the engine." Instead, it would simply request some high level SignalK path that encompasses that list of maintenance items, and using PUT, those items could perform updates, giving you the CRU of CRUD. The only thing missing would be supporting the http DELETE operation to get full CRUD (though I suppose you could fake that with a PUT of some app specific "delete" operation.)
Would there be a problem with having potentially hundreds or thousands of items as part of the SignalK model (some of those those data points would be the complete history of a specific maintenance item). If so, where would you draw the line, if anywhere? As another example, a "tide prediction" plugin I have already written takes a depth data sample once every 5 minutes, and it organizes those samples into different "locations" to support anchoring at different areas. Should the locations be part of the SignalK model? How about the individual samples? If they all were, there really would be no reason for any plugin UI to have to communicate directly with its plugin using any type of protocol other than the "official SignalK api", which would be extended to support full CRUD semantics on certain paths.
Of course, how persistence is implemented is still a question up in the air - we've talked SQLite, NoSQL, etc. The plugin's persistence model may still be SQLite on the backend. This discussion is really about how the entity data get communicated with a UI. How should plugin developers approach things?
I am interested in the development community's thoughts. Is the vision for SignalK to have EVERYTHING that may be related to the boat and its operation be SignalK, including the care and feeding of the vessel? Or, should there be a more refined view of what is and what is not something that is valuable to be part of the SignalK stream (e.g. limit it to the daily operations).