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: