Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Google Summer of Code 2018 Ideas"

(Added Hono protocol adapter ideas)
(Eclipse Hono: Web frontend for device registry: fix missing mentor)
Line 16: Line 16:
 
* An automated UI test
 
* An automated UI test
 
* A mobile version of the UI
 
* A mobile version of the UI
 +
 +
*'''Possible Mentors:''' [[User:Jreimann.redhat.com|Jens Reimann]]
  
 
= [http://eclipse.org/hono Eclipse Hono]: AMQP protocol adapter =
 
= [http://eclipse.org/hono Eclipse Hono]: AMQP protocol adapter =

Revision as of 05:23, 19 January 2018

Warning2.png
Project team member and potential mentors, add your content here. The format suggested below is just an idea. Play with the layout, but please don't mess with content provided by other projects. Please be sure to follow branding guidelines (e.g. "Eclipse Dash", not "Dash"). Putting things in alphabetical order seems like a fair thing to do. Links to content hosted elsewhere are fine, but bear in mind that this page will likely be the main point of contact for people who are not already inside your community.


Eclipse Hono: Web frontend for device registry

Eclipse Hono Eclipse Hono™ provides remote service interfaces for connecting large numbers of IoT devices to a back end and interacting with them in a uniform way regardless of the device communication protocol.

The goal of this project would be to develop a simple web frontend for the already existing device registry. Allowing users to view and manage users and devices. For this the existing API should be used when possible. If necessary the backend can be extended with new APIs. Existing technologies and libraries should be re-used.

The tasks would be:

  • Draft a UI
  • Evaluate and choose a frontend technology stack
  • Define necessary APIs
  • Do the actual frontend implementation, backend if necessary

Optionally there could be:

  • An automated UI test
  • A mobile version of the UI

Eclipse Hono: AMQP protocol adapter

Eclipse Hono Eclipse Hono™ provides remote service interfaces for connecting large numbers of IoT devices to a back end and interacting with them in a uniform way regardless of the device communication protocol.

For connecting to devices/gateways Hono allows the use of different protocol adapters in order to normalize the payloads to the internal AMQP 1.0 based network. Current protocol adapters are HTTP and MQTT. However it would be nice to use the flow control features of AMQP 1.0 also from the device/gateway layer. In order to perform authentication and normalization it would be necessary to create an AMQP adapter. Tapping directly into the internal AMQP network is not an option.

The tasks would be:

  • Draft an AMQP 1.0 based API for communicating with the protocol adapter
  • Create an implementation of the protocol adapter based on the vert.x proton library
  • Create unit tests

Optionally there could be:

  • A scale test/performance test

Eclipse Hono: CoAP protocol adapter

Eclipse Hono Eclipse Hono™ provides remote service interfaces for connecting large numbers of IoT devices to a back end and interacting with them in a uniform way regardless of the device communication protocol.

For connecting to devices/gateways Hono allows the use of different protocol adapters in order to normalize the payloads to the internal AMQP 1.0 based network. Current protocol adapters are HTTP and MQTT. Adding CoAP to the list of supported protocols would be a fine extension.

The tasks would be:

  • Draft a CoAP based API for communicating with the protocol adapter
  • Create an implementation of CoAP protocol adapter based on Eclipse Californium
  • Create unit tests

Optionally there could be:

  • A scale test/performance test

Eclipse OMR

Eclipse OMR provides reliable C and C++ high performance components (garbage collector, Just In Time compiler, platform porting library, asynchronous event handling, tracing, diagnostics, ...) for building all kinds of language runtimes such as Java, Ruby, Python, Lua, etc. These components were originally distilled and contributed from the IBM J9 Java Virtual Machine and made available for use in other language runtimes. The OMR project also includes a library called JitBuilder, which lets you create a JIT compiler for a new language relatively quickly.

Our ultimate goal is to build an open reusable language runtime foundation for cloud platforms in full cooperation with existing language communities. There are currently OMR based runtimes for Java (IBM J9), CRuby (Ruby+OMR Technology Preview), Lua (Lua Vermelha), Smalltalk (SOM++ with OMR), Rosie Pattern Language, Base9 (an ultra simple runtime for workshop-based learning about the OMR JitBuilder library).

Here are some of our project ideas :

  • Port a (subset of a) new language or runtime to use OMR (e.g. Python,R, Julia, make a suggestion!) using the JitBuilder library
  • Use JitBuilder to dynamically compile native code to accelerate some application (e.g. Apache Spark, NumPy/SciPy, or make a suggestion!)
  • Implement a general/dynamic object model. The object model should support Javascript and Ruby.
  • Port JitBuilder interface to another language (e.g. Ruby, Python, make a suggestion!)
    • Java bindings exist so you can write Java code to dynamically generate native code callable as a JNI method
    • similar model could be applied to another language or possibly using SWIG to make JitBuilder accessible from more languages
  • Port OMR to a new hardware platform (e.g. ARM64)
  • Enhance Intel processor vector instruction support in the OMR compiler
    • add support for 256- and 512-wide vector data types and enhance JitBuilder interface to handle different width data
    • showcase with JIT compiled vectorized code!

Eclipse Dash

NOTE that this is basically a placeholder to give mentors an idea of how they might format a section of their own. This may actually survive as an idea to present to students, but--by way of expectation management--expect that it will disappear.

Eclipse Dash is a place where the community itself can collaborate on tools for community awareness and collaboration in support of our ultimate objective of committer quality and cooperation. This is very much a research project as we are not entirely sure what these tools will be.

Here are some of our project ideas:

  • Extend the Eclipse Dash Gently Dependency analysis tools to identify the use of third-party JavaScript libraries bug 509617
  • Update the IP cartoons and move them to the handbook bug 498290

Back to the top