Difference between revisions of "VPP/Java API/Plugin support"
From fd.io
(Created page with "This page is a design proposal for Java API to support VPP plugins.") |
(Initial draft) |
||
| Line 1: | Line 1: | ||
This page is a design proposal for Java API to support VPP plugins. | This page is a design proposal for Java API to support VPP plugins. | ||
| + | |||
| + | == Architecture == | ||
| + | |||
| + | [[File:JVPP Architecture.png|http://yuml.me/edit/cf23df5c]] | ||
| + | |||
| + | == Main assumptions == | ||
| + | |||
| + | * JVppRegistry holds a map of callback interfaces for JVppCore and plugins (generated together with JNI implementations based on provided api files). | ||
| + | |||
| + | * when API user sends a message, JVppRegistry delegates the call to JNI implementation provided by the particular plugin (JVppCore can be viewed as a plugin that is allways present). | ||
| + | |||
| + | * when JNI code receives reply, it asks the registry for appropriate callback interface and invokes callback method that corresponds to the received message reply | ||
| + | |||
| + | == Problems needs to be solved == | ||
| + | |||
| + | * check if single connection can be used (solve linking and shared memory issues) - prototype in progress | ||
| + | * provide FutureJVppFacade and CallbackJVppFacade for all plugins (prototype in progress) | ||
| + | * util.py that stores workarounds for messages that are not following vpe.api naming conventions needs to be extensible, just in case vpp plugins have their own peculiarities | ||
| + | * Java binding generator for plugins should be easily referenced during plugin build (ideally new fd.io project). | ||
Revision as of 13:07, 19 July 2016
This page is a design proposal for Java API to support VPP plugins.
Architecture
Main assumptions
- JVppRegistry holds a map of callback interfaces for JVppCore and plugins (generated together with JNI implementations based on provided api files).
- when API user sends a message, JVppRegistry delegates the call to JNI implementation provided by the particular plugin (JVppCore can be viewed as a plugin that is allways present).
- when JNI code receives reply, it asks the registry for appropriate callback interface and invokes callback method that corresponds to the received message reply
Problems needs to be solved
- check if single connection can be used (solve linking and shared memory issues) - prototype in progress
- provide FutureJVppFacade and CallbackJVppFacade for all plugins (prototype in progress)
- util.py that stores workarounds for messages that are not following vpe.api naming conventions needs to be extensible, just in case vpp plugins have their own peculiarities
- Java binding generator for plugins should be easily referenced during plugin build (ideally new fd.io project).
