|
| Re: Higher level APIs [message #1741824 is a reply to message #1741796] |
Mon, 29 August 2016 22:08   |
 David Woodard
Messages: 420
Registered: July 2014 |
Senior Member |
|
|
Hi Brad,
I commented in another post, but I will repeat here. I agree with you, having this sort of abstraction for Eclipse Kura would be great. However, as a general construct, we try and keep Kura as light of a framework as possible. There are just too many verticals in the IoT space to try and make a generic API layer like you describe. However, if you are working with RFID for example, it would be great if you could simply grab an "add on" that enabled Kura for RFID.
We have recently added Eclipse Kura to the Eclipse Marketplace. Eventually we will add all of our example projects there, but libraries like you describe may also fit well. If this is something you would like to contribute, let me know, I would be happy to work with you.
Thanks,
--Dave
|
|
|
| Re: Higher level APIs [message #1750921 is a reply to message #1741824] |
Mon, 02 January 2017 01:41 |
Brad Johnson
Messages: 6
Registered: August 2016 |
Junior Member |
|
|
I'm finally in the position where I may be able to start working more with the framework and libraries. I agree that there are far too many verticals out there that might make for an explosion of possible implementations. Perhaps something outside the Kura project or even a sub-project would be appropriate. I'm really thinking of a set of API interfaces that could be used via OSGi services and not concrete implementations. Very basic API interfaces could then be extended by more specific interfaces. A simple example would be something like an LED where one might have a Toggle interface, Range interface and an Output interface extended by the LED interface. Note that none of the actual configuration details or mechanisms are exposed. But if I inject an LED OSGi service into my bundle then I'm not as concerned about the configuration values since they are abstracted away. I'm making those APIs up off the top of my head so take them with a grain of salt. The Range API might simply specify a method that takes a number from 1 to 100. In the case of the LED that might map in a configuration file to various values for each.
But when develop an application I would simply call on(), off(), toggle(). Or I might call setRange(50) to set the value to 50%. Obviously if there isn't an implementation for the OSGi service exposed that way then nothing will happen. But I don't care about the voltage or any other concrete configuration settings in my code. I can swap different components in and out and my code, via the interface, simply sets the value to 50% or toggles on/off.
Your example of the RFID is another good case in point. One really can't specify all the possible mechanisms of an RFID sensor. In this case it is likely my bundle would implement some RFID sensor listener interface that I register as an OSGi service to be picked up by the concrete implementation of the sensor/reader provided by the manufacturer. They would then send events, perhaps, based on triggered values. Perhaps there could be normalized values expected in those events that the manufacturer (or whoever implements) would have to map.
If I have a FooCorpRFIDSensor implementation bundle it may well have a lot of other methods on it. But if I have an application that registers as a listener for RFID sensor events then I should be able to switch from a BarRFIDSensor to a FooRFIDSesnor without changing my code. That would usually mean that the RFID sensor listener interface would only have a small subset of what RFID sensors might provide. In the case of a listener service, in fact, it would receive an event that implements RFIDSensorEvent that would return some basic data but might well have a lot of other data that it carries with it. While that might entail casting the RFIDSensorEvent to a specific type of RFIDSensorEvent that is a child interface or event to a FooSensorEvent in order to get the requisite data, the OSGi registration mechanics would not change.
Setting up these sorts of API bundles would also help enforce the encapsulation of the implementation classes. My FooRFIDSensorEventImpl shouldn't be exposed or importable by another bundle. The FooSensorEvent interface would be and the interface it extends would be as well.
I say these concrete implementations would be implemented by the manufacturers. That would likely come in time if the framework becomes very popular. Obviously that can have a cascade effect over time as implementations of the APIs provide springboards for other implementations.
At the basic level then one might have two standard API bundles - sensor and actuator. Those APIs interfaces would all be public. Implementations could extend interfaces from either or both while keeping implementation details nicely tucked away. That would definitely help facilitate semantic versioning of bundles as implementations are hidden and prevent developers from coupling to their code to them.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02965 seconds
] 
Search
Help
Register
Login
Home
