You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 21, 2020. It is now read-only.
Before the final v0.1.0 let's add a metadata / plugin activation RPC method, since JSON-RPC over HTTP specs ( here and here ) on their own do not specify means for API versioning.
The metadata RPC method can inspiration from the Docker plugin API Handshake API -- proposal below.
Metadata / Handshake API
This design is inspired by the handshake api
for Docker plugins:
Each plugin will implement a new RPC method /Plugin.Meta which will accept a HTTP POST with empty body and returns
{ "Implements": [ "Instance/0.1" ] }
Notes
A plugin can implement multiple interfaces (note the array)
There may be additional fields in this struct which will give example request / response structs (Design TBD - will update in this thread).
wfarner
changed the title
Versions
Include versioning information in plugin APIs
Nov 30, 2016
There may be additional fields in this struct which will give example request / response structs
I'd like to suggest that we peel the above off as a separate issue/effort, and not make it a blocker for 0.1.0. It's nice to have, but i think it is non-critical for a release.
We are about to publish two infrakit third party plugins. We were wondering how to tie our plugins to a specific release or revision?
To be more specific for example recently you changed
infrakit group watch
tocommit
. Having a plugin tutorial might look incorrect after a change.Also since plugins implement
instance.Plugin
do you plan to change the interface sometimes in the future?The text was updated successfully, but these errors were encountered: