355
edits
Labs/Bespin/DesignDocs/PluginAPI: Difference between revisions
no edit summary
No edit summary |
|||
| Line 8: | Line 8: | ||
For this we want a plugin API. The goal is for this API to be as simple as possible. | For this we want a plugin API. The goal is for this API to be as simple as possible. | ||
As well as commands and the config work, we also have the low level construct of the publish/subscribe event system that you can tie into. | As well as commands and the config work, we also have the low level construct of the publish/subscribe event system that you can tie into. This shows that there are actually a couple of pieces to a plugin API: | ||
* First, we need an API that allows you to register and activate new plugin code | |||
* Second, we need public APIs to let plugins easily get done what they need too, without having to go deep into the code, and accessing APIs that are a known public contract. This is vital to the goal of rapid innovation without constantly breaking plugins. | |||
== Core Plugin API == | |||
Here we will talk about the first goal, the core plugin API itself | |||
=== Wordpress-like === | === Wordpress-like === | ||
| Line 51: | Line 56: | ||
url: "http://foo.com/bespinPlugin.zip" | url: "http://foo.com/bespinPlugin.zip" | ||
}); | }); | ||
=== Server and Client Plugins === | |||
One *future* item that we are excited to explore is the notion of a plugin that can not only contain client code to change the editor or dashboard, but also deploy server changes. | |||
This would be pretty unique, and would enable feature rich changes across the stack. | |||