|Re: [ecf-dev] GSoC 2016 - ECF Project Ideas|
The reason that I haven't put project ideas up for GSoC 2016 is that I personally don't have any resources (time) available to be a mentor for such projects. If others are able/willing to do so, I would be happy to have other committers and/or ECF contributors (or even users) provide mentoring for you and/or other GSoC 2016 students, but short of some resources available to support my time spent working on ECF, I can't personally commit to mentoring such a project this year. My apologies for that.
However, there are several threads of effort that I've been leading that I would like to see GSoC projects around:
1) Continued work on Tooling additions for ECF's Remote Services/Remote Service Admin implementation . There's been quite a lot of additions there over the past two releases . Some ideas here: Enhancing the views/UI that are already present, creating new/other views (e.g. a 'remote services dependencies' view), adding API to allow for keeping track of meta-data for remote service distribution providers (e.g. number of remote invocations/number of round trips, bandwidth consumed, timing/performance information, etc). The listing of info from Gsoc 2015 is still relevant , but several things have been accomplished (although there are many more...e.g. a greater focus on tooling associated with the Internet of Things use cases).
2) Continued work on Remote Management introduced in . These additions enable a very large set of management functions...from the OSGi framework management (e.g. framework, bundles, services, wiring) to declarative services/SCR remote management, to p2/provisioning management. There is currently very little user interface for these remote management APIs (although there is some associated with 2).
3) There was some work on using Vaadin to present a web-based UI for the Remote Services Tooling. This would make it very easy (for example) to use the remote management work for managing OSGi server instances (such as Karaf ).
4) These days there's a lot of attention to 'micro services', 'containers', and 'Kubernetes'. I'm of the opinion that ECF Remote Services presents an ideal: transport independent, potentially language-independent, dynamic, high-level standardized model (OSGi Remote Services) for micro containers...both for exposing remote services, as well as for remote management and monitoring of multi-node distributed systems (e.g. Kubernetes).
5) ECF has a number of distribution providers now , and some of them (e.g. JaxRS, Hazelcast, MQTT) could use some additional/new example remote services, documentation, tutorials, testing, etc.
6) In ECF 3.16.0 there are some more additions to make it easier to create new ECF distribution providers. For example, see  which was recently added by me. It would be nice to have additional distribution providers, perhaps based upon RMI, or Fabric8/Hawt.io...which has already been done by someone on the Karaf users list, or other transports (e.g. one of the Internet of Things protocols like  or COAP . With the new distribution provider API  being introduced in 3.13.0, I think this would be straightforward.
7) It would be very nice to update our version of Zookeeper that we are deploying . This would likely have to involve Wim Jongman (committer responsible for zookeeper in ECF) as mentor so I can't speak for Wim.
8) We are in great need of releng contributions for...e.g. .
9) In the past we've worked on using Python for remote services/Remote Service Admin. For example see iPopo . It would be very nice to allow easy interoperability between Python and Java for remote services using the Remote Service Admin APIs. With ECF's impl this is quite easy, because we have a pluggable distribution provider structure and much of the necessary support for that exists with iPopo already. I've also had some recent contact with Thomas Calmant, who is one of the iPopo project team members.
10) There are certainly other things I'm not thinking of...e.g. additional tooling that we've discussed, additional distribution providers, documentation/examples/tutorials we need lots more of those as well.
I think that's enough. It's pretty clear to me that we have more things that we would like to do than we have resources to do.
On 3/13/2016 11:35 AM, Osanda Wedamulla wrote: