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.
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?
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
Hi,
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
REST-API
-- Eventing: request
-- Consumers: OP-Plugins, other external Tools
-- Payload: everything (text, file up/download)
Recommendation: external tools, on demand request of data
Eventbus
-- Eventing: fire events. Subscribing or implementing on_event-Hook
-- Consumers: OP-Plugins
-- Payload: JSON
Recommendation: propagating (realtime) data changes to other plugins
Helpers
-- 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
send_plugin_message
-- 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.
