Opinions on data exchange between plugins


currently my DisplayLayerProgress-Plugin provides two stable interfaces for "3rd-Party"-Deveopers. With this approach they can include the DLP-Values in there OP-Plugins or in there Client-Application.

But in the past I received "tickets" that someone is subscribing to the DLP-Knockout-Viewmodel and after I changed the Viewmodel "nothing" is working anymore.

Now I received a ticket that I changed the payload-structure that I am sending via send_plugin_message from server to the client: https://github.com/OllisGit/OctoPrint-DisplayLayerProgress/issues/136 ...and "nothing" is working anymore.

In the ticket you can find my current suggested solutions: 1) I can add stable payload to the regular ui-payload or 2) send stable payload with a second plugin-identifier

Question: What is the "best" approach? What interfaces should a Plugin-Developer provide for other Developers?

Thx, in advance

Helpers. If we need a better mechanism than that (e.g. for frontend stuff) I'd be happy to brainstorm.

Good documentation, backwards compatible changes when possible, and known / published communication channel(s). If incompatible changes are needed, you can document and communicate through the already established paths.

OctoPrint is a good example of a project that behaves in this way :smiley:

I never realized the helper feature. In my opinion it looks like a service provider and not a data exchange mechanism.
Yes, you can do something like otherHelper.get_current_values() or more service like otherHelper.calculate.filament_lenght()

I collected all Interface-Mechanism we have in OP and wrote down my recommendations. Maybe we can discuss on that and "sharpen" my view in Plugin-Interfaces :wink:

-- Eventing: request
-- Consumers: OP-Plugins, other external Tools
-- Payload: everything (text, file up/download)
Recommendation: external tools, on demand request of data

-- Eventing: fire events. Subscribing or implementing on_event-Hook
-- Consumers: OP-Plugins
-- Payload: JSON
Recommendation: propagating (realtime) data changes to other plugins

-- Eventing: request. Receive helpers from self._plugin_manager.get_helpers. Execute methods.
-- Consumers: OP-Plugins
-- Payload: Method-Signature
Recommendation: Provide service functionality on demand to other plugins

-- Eventing: publish/subscribe. Push data to UI via WebSocket. JavaScript listen on onDataUpdaterPluginMessage
-- Consumers: Own UI-Plugin and other UI-Plugins
-- Payload: JSON
Recommendation: propagating (realtime) data changes to other ui-plugins

knockout based viewmodel-subscribing
-- Eventing: grabing viewmodel and subsribe on attributes
-- Consumers: OP-Plugins
-- Payload: JSON and single field values
Recommendation: don't use it, maybe for OP-Viewmodels that are stable for years

Totally agree with you @b-morgen: good documentation, stable interface, etc. In the current situation I don't know that someone is hijacking an none propagated interface.

To solve the mentioned issue, my plan is to send a second web socket-call with a stable payload under a different identifier. Then I am independent with my own view-model-payload.

I used to write interfaces for things like bank transactions, EDI and things like that. I think the wisdom from all that was that things change over time.

VERB /api/v1.1/node
VERB /api/v1.2/node