Hi Thomas, This picture just takes NSH_SFC plugin for example. You could replace it with any other plugins. They share the same framework.
Thanks, Hongjun From: vpp-dev-boun...@lists.fd.io [mailto:vpp-dev-boun...@lists.fd.io] On Behalf Of Thomas F Herbert Sent: Thursday, October 27, 2016 9:55 PM To: vpp-dev@lists.fd.io Subject: Re: [vpp-dev] [honeycomb-dev] jVpp as independent fd.io project On 10/27/2016 06:57 AM, Ni, Hongjun wrote: Hey, >From the attachment: JVPP.PNG The JVPP code is located in VPP project, but from the logical perspective, the JVPP should be within Honeycomb. This is weird. So it is better to separate JVPP (Red piece in the picture) from VPP and Honeycomb. Besides, if customers only want to use VPP's binary APIs, then they could have small image without JVPP code. But to complicate matters, it looks like your pic below is specific to NSH_SFC Regards, Hongjun -----Original Message----- From: honeycomb-dev-boun...@lists.fd.io<mailto:honeycomb-dev-boun...@lists.fd.io> [mailto:honeycomb-dev-boun...@lists.fd.io] On Behalf Of Maros Marsalek -X (mmarsale - PANTHEON TECHNOLOGIES at Cisco) Sent: Thursday, October 27, 2016 4:27 PM To: Kinsella, Ray <ray.kinse...@intel.com><mailto:ray.kinse...@intel.com>; Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) <mgrad...@cisco.com><mailto:mgrad...@cisco.com>; vpp-dev <vpp-dev@lists.fd.io><mailto:vpp-dev@lists.fd.io>; honeycomb-dev <honeycomb-...@lists.fd.io><mailto:honeycomb-...@lists.fd.io> Cc: Ed Warnicke (eaw) <e...@cisco.com><mailto:e...@cisco.com> Subject: Re: [honeycomb-dev] [vpp-dev] jVpp as independent fd.io project Hey Ray, >From usability perspective, you are right, JVPP is not useful outside of VPP. But on the other hand, VPP plugins are also not useful outside of VPP but they still get dedicated projects. Same applies for Honeycomb (the VPP specific distribution of HC at least), it is not useful without VPP. However, dedicated projects allow for separation of control and enable better control over the codebase. That's what we want for JVPP, we want better control out of this. Plus we think this would bring benefits to VPP project as well (as Marek mentioned). Another plus is that it will not require VPP committers to spend time reviewing/merging JVPP code, since that's what we(the devs of JVPP) should be doing. Currently, I'm aware of 2 language bindings on top of VPP's binary APIs: Python and Java. But in the future as new language bindings come, I don't think VPP should host all of them and all of their committers. Regards, Maros -----Original Message----- From: honeycomb-dev-boun...@lists.fd.io<mailto:honeycomb-dev-boun...@lists.fd.io> [mailto:honeycomb-dev-boun...@lists.fd.io] On Behalf Of Kinsella, Ray Sent: Wednesday, October 26, 2016 11:52 AM To: Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) <mgrad...@cisco.com><mailto:mgrad...@cisco.com>; vpp-dev <vpp-dev@lists.fd.io><mailto:vpp-dev@lists.fd.io>; honeycomb-dev <honeycomb-...@lists.fd.io><mailto:honeycomb-...@lists.fd.io> Cc: Ed Warnicke (eaw) <e...@cisco.com><mailto:e...@cisco.com> Subject: Re: [honeycomb-dev] [vpp-dev] jVpp as independent fd.io project Hi Marek, I am not sure that jVpp is useful outside of VPP, So outside of helping with 1), I am not sure what the benefit would be. I would have to imagine 1) is fixable in some other way. Ray K On 26/10/2016 08:06, Marek Gradzki -X (mgradzki - PANTHEON TECHNOLOGIES at Cisco) wrote: Hi, this is follow-up to the discussion started on the last VPP weekly meeting. In my opinion, the biggest advantages are: 1) it would make VPP build faster and more stable 2) it would make possible to use build system that supports dependency management and hence is more suitable for java build (e.g. Maven or Gradle) Having 2) we could for example translate vpe.api to yang (messages as RPCs), generate Java bindings (requires yangtools from ODL) and have NETCONF support in HC for all VPP APIs. The jVpp project could have two parts: - Java API generator that could be referenced from outside (e.g. in form of a maven plugin) - actual API generation for all the plugins that live in VPP codebase, other fd.io plugins (e.g. NSH) could be also included or use API generator. Regards, Marek _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev _______________________________________________ honeycomb-dev mailing list honeycomb-...@lists.fd.io<mailto:honeycomb-...@lists.fd.io> https://lists.fd.io/mailman/listinfo/honeycomb-dev _______________________________________________ honeycomb-dev mailing list honeycomb-...@lists.fd.io<mailto:honeycomb-...@lists.fd.io> https://lists.fd.io/mailman/listinfo/honeycomb-dev _______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io> https://lists.fd.io/mailman/listinfo/vpp-dev -- Thomas F Herbert SDN Group Office of Technology Red Hat
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
