Hi Osanda,
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 [1]. There's been
quite a lot of additions there over the past two releases
[2][3]. 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 [4], 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 [2][5].
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[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 [6]).
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 [7], 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 [8]
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 [9] or COAP [10]. With the new
distribution provider API [8] 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 [11]. 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. [12].
9) In the past we've worked on using Python for remote
services/Remote Service Admin. For example see iPopo [13]. 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.
Thanks,
Scott
[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=454609
[2]
https://www.eclipse.org/ecf/NewAndNoteworthy.html
[3]
https://www.eclipse.org/ecf/NewAndNoteworthy_3.12.0.html
[4]
https://wiki.eclipse.org/Google_Summer_of_Code_2015_Ideas#Eclipse_Communication_Framework:_Tooling_for_Remote_Services
[5]
https://github.com/ECF/OSGIRemoteManagement
[6]
https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf
[7]
http://wiki.eclipse.org/Distribution_Providers
[8]
https://github.com/ECF/ExampleRSADistributionProviders
[9]
https://projects.eclipse.org/proposals/milo
[10]
http://www.eclipse.org/californium/
[11]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=434166
[12]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=396457
[13]
http://ipopo.coderxpress.net/wiki/doku.php
On 3/13/2016 11:35 AM, Osanda Wedamulla wrote:
