karaf-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Red Hat" <bradj...@redhat.com>
Subject Karaf IoT
Date Mon, 02 Jan 2017 00:37:38 GMT
I was looking at the Kura project for future development and a move toward
IoT development.  Unfortunately I have several issues with the project which
are not going to be solved by simply becoming a contributor.  It made me
wonder if there's been any discussion about a similar project using
Felix/Karaf/Camel/Maven and related plugins? It isn't even that the projects
necessarily need to be competitive.  Many things like driver libraries could
be shared. Since the Kura drivers should already bundles repurposing or
simply using them shouldn't be that difficult. 

 

There are a few aspects of a Felix/Karaf/Aries that lend themselves to such
an implementation.  The Karaf 4 profiles mechanics are a perfect mechanism
for creating a testable, self-contained application that can be run on a
developers machine during development and then the zip file can be moved to
whatever device one is working with and unzipped.  That's about as easy an
installation as I can think of.  Since that minimalist karaf 4
implementation is so small and the provisioning is static at compile time it
hits the nail on the head.  When I put together a project recently and
included CXF and a number of other libraries the whole thing was about 30MB.

 

The PAX CDI mechanisms make wiring up beans and routes a lot easier.  That
certainly could make writing applications for small devices a lot easier. 

 

Just one simple example from the sample code: 

 

GPIOPinConfig pinConfig = new GPIOPinConfig(

               DeviceConfig.DEFAULT,
//GPIO Controller number or name

               17,
//GPIO Pin number

               GPIOPinConfig.DIR_INPUT_ONLY,
//Pin direction

               GPIOPinConfig.MODE_INPUT_PULL_DOWN,
//Pin resistor

               GPIOPinConfig.TRIGGER_BOTH_EDGES,
//Triggers

               false
//initial value (for outputs)

);

 

GPIOPin button = (GPIOPin) DeviceManager.open(GPIOPin.class, pinConfig);

 

Seem to beg for OSGi services (DS or blueprint), annotations, and simple cfg
files. Something like that GPIOPin or even a GPIO connector could really be
injectable OSGi services with all the configuration tucked in the cfg or
with defaults in blueprint properties or DS annotations. Somehow I suspect
the DeviceManager is not a service factory but I didn't dig in.  There were
too many parts of the project that really didn't appeal to me. 

 

In any case, there's probably some discussion about this already.

 

Brad

 

 


Mime
View raw message