Not yet…I’m trying to find out if there are existing projects that might be interested or already working on either Karaf or appropriate OSGi services for boards, sensors and actuators. It certainly is a project I’ll set up if there isn’t any interest elsewhere. Kura might not be the place for it and while Karaf/Felix is important to me, it can leverage the existing Kura bundles without necessarily being a part of that project. So I’ll definitely be involved in some Karaf deployment/implementation mechanism.
I did post on the Kura forum today asking about interest. Part of what drives this is going to be their mission statement and interest. At the very least, for the project to be useful, the board level device concerns and configurations have to be abstracted behind service and service factory interfaces for the supported boards and their devices. The sample code on the Kura project shows some abstraction levels that would be appropriate for creating sensor/actuator bundles but it needs to hew to OSGi idioms more. That obviously isn’t a Karaf specific concern but is an OSGi library concern that we all share. I really want to make sure I’m not coming off as busting on the Kura project here. It is based on Pi4j which has support for a lot of different boards. This code sample appears to have the sort of abstraction I’d expect a sensor/actuator driver bundle to use. A developer or manufacturer interested in providing an implementation bundle for a specific sensor or actuator can inject the DS ModBus service and bind to it. It is still showing pin and register level access though which binds it to a specific board implementation as far as I can tell. http://eclipse.github.io/kura/doc/kura-modbus-driver.html By contrast this sample is calling across classloaders to a device manager and explicitly setting pin configuration instead of configuring it at a board level, exporting as a service, and injecting it into a consumer bundle. That configuration is board specific and should be tucked away, done solely via configuration and exported. http://eclipse.github.io/kura/doc/kura-dio-apis.html Those board level bundles should be exporting services and service factories that are purely set up via configuration. That permits the intermediary bundles for sensors and actuators to bind to them without configuring them. The configuration of the pins/services should be associate with the board level bundles. Moving from one board to another should be a simple matter of changing board level configuration without requiring modifications to sensor/actuator bundles and especially without changes to application level bundles that use sensor/actuator service interfaces. (Yeah, life is never that simple but it’s a good goal I think). The injection of services like GpioPin might use LDAP filtering for export and import (or other mechanism so that pin numbers and configuration are not exposed.) Moving from board to board then is matter of configuring the board level exports to set up pins and expose them as services with via a given name. And Karaf 4 is a spectacular way to zip an application and all its dependencies for deployment. Once some service interfaces for sensors and actuators are developed, then simulators for those could be created permitting easy development of applications on the desktop. Perhaps those would also provide reference implementations for developing tests suites against that driver manufacturers could use to determine if their sensor or actuator bundle actually complies with the standard. Brad From: Jason Pratt [mailto:jpratt3...@gmail.com] Sent: Wednesday, January 4, 2017 12:05 PM To: user@karaf.apache.org Subject: Re: Karaf IoT scott/brad do you guys have a repo setup for this project? On Wed, Jan 4, 2017 at 9:39 AM, Brad Red Hat <bradj...@redhat.com <mailto:bradj...@redhat.com> > wrote: I'll certainly look at that a bit more. My concerns about Kura project have as much to do with the project's level of abstraction and I can bring it up there. I did ask about their intentions with service interfaces. As I've dug into it deeper and thought about "the vision thing", to quote a US president, I laid out some of those thoughts. https://enjekt.org/2017/01/04/iot-and-the-abstraction-of-things/ Because it is an Eclipse project I wasn't sure that they'd be interested in Karaf/Felix but can check. I've heard that they have, in fact, opened a Jira ticket about it. So they may be interested. It isn't just about a Karaf implementation although it is certainly about that as well. I'm also concerned about the intermediary libraries/services that abstract developers away from low level details of pin outs in order to make application code portable. Obviously the intermediate level concerns really don't belong with Kura or Karaf so I won't discuss those here. Suffice it to say I'd like to see that intermediate set of libraries become a "sticky" place where developers and sensor/actuator manufacturers go to add new high level device specific bundles for use in applications. Brad -----Original Message----- From: Scott Lewis [mailto:sle...@composent.com <mailto:sle...@composent.com> ] Sent: Tuesday, January 3, 2017 9:33 PM To: user@karaf.apache.org <mailto:user@karaf.apache.org> Subject: Re: Karaf IoT On 1/2/2017 11:35 AM, Brad Red Hat wrote: > I certainly understand the "short of time" problem. It just happens > that I have a bit of a window right now and would like to get into it a bit deeper. > > > Whether a Karaf/PAX/Felix implementation is more appropriate under the > aegis of Kura or as a separate project that leverages the Kura driver > bundles is hard to say. I guess that would depend on a couple of things. > > 1. How amenable they are to a more top down approach that starts with > OSGi service mechanics and drives down to meet the driver bundles? > 2. Does an Eclipse foundation project have any interest in an Karaf > branch project? The ECF project would be interested in such an effort [1]. We have been/are distributing our impl of the OSGi Remote Services/RSA specs [2] as Karaf features [3] and have recently been exploring using remote services for Karaf management [4]. Also, in my interaction with some of the Kura committers it's become clear that they are doing some prototyping of running Kura services on Karaf [5]. I don't know whether they have release plans around that work, but I know that it has been going on. It might be useful to convey to them directly what your desires/criticisms are, and perhaps contribute to that work. Scott [1] http://www.eclipse.org/ecf [2] https://wiki.eclipse.org/Eclipse_Communication_Framework_Project#OSGi_Remote _Services [3] https://wiki.eclipse.org/EIG:Install_into_Apache_Karaf [4] https://wiki.eclipse.org/Karaf_Remote_Management_with_Eclipse [5] https://dev.eclipse.org/mhonarc/lists/kura-dev/
