Difference between revisions of "VPP/Java API/Plugin support"

From fd.io
< VPP‎ | Java API
Jump to: navigation, search
m
(Problems needs to be solved)
Line 17: Line 17:
 
* check if single connection can be used (solve linking and shared memory issues) - prototype in progress
 
* 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)
 
* 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
+
* util.py stores workarounds for messages that are not following vpe.api naming conventions. It 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).
 
* Java binding generator for plugins should be easily referenced during plugin build (ideally new fd.io project).

Revision as of 13:11, 19 July 2016

This page is a design proposal for Java API to support VPP plugins.

Architecture

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
  • 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 stores workarounds for messages that are not following vpe.api naming conventions. It 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).