Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[ecf-dev] pi4j and OSGi (remote) services
Hi Folks,

I've bin examining the pi4j API and usage examples and have some initial thoughts about making declaring some OSGi service types...that can be used as OSGi services.  

This is mostly a stream of consciousness right now, to get public design discussion started.  It's not intended to be a finished API design :)

1) All the examples (e.g. the gpio control example [1]) essentially start with this call:

       // create gpio controller
        final GpioController gpio = GpioFactory.getInstance();
With OSGi services, this singleton impl is pretty much an anti-pattern, and is easily replaced with a ServiceFactory that would registered something like this:

context.registerService(IGPIOController.class, new GPIOServiceFactory(), props);

Then consumers of this service (remote or not) could simply get IGPIOController instances from the OSGi service registry through the normal methods (DS, ServiceTracker, etc).  This will allow all kinds of dynamics goodness from OSGi (e.g. versioning, etc).

2) Once the GpioController instance is acquired, the typical usage pattern seems to be:

a) 'provision' a pin

e.g.

// provision gpio pin #01 as an output pin and turn on
        final GpioPinDigitalOutput pin = gpio.provisionDigitalOutputPin(RaspiPin.GPIO_01, "MyLED"
, PinState.HIGH);
        System.out.println("--> GPIO state should be: ON");
b) Use the returned pin (in this case instance of GpioPinDigitalOutput) to set of change the pin's state...e.g. to turn off whatever is connected to that pin:

 // turn off gpio pin #01
        pin.low();
        System.out.println("--> GPIO state should be: OFF");
or toggle

// toggle the current state of gpio pin #01 (should turn on)
        pin.toggle();
        System.out.println("--> GPIO state should be: ON");

One question immediately rolling around in my head...WRT modelling gpio interaction with OSGi services/remote services...is the following:  how to model this 'provision' operation on a/some controller.  

One way would be to do something very much like what pi4j does..e.g. have a IGPIOController service, with provision* methods on it that return GpioPin* instances.  Another way would be to have GpioPin* like instances (of some new interface that we declare) actually be service instances in the pi service host service registry.   There would be some nice advantages of that approach, I believe, that come for free for the GpioPin* instances being actual OSGi services, but I'm currently not clear on how/when the GpioController.provision* method invoke would be done...especially with the appropriate arguments.

Ok, I would like to keep these discussions bite-sized so I'm going to stop there and see what people's ideas are WRT this controller->provision->use gpio pin instance structure as OSGi services.

Thanks,

Scott

[1] http://pi4j.com/example/control.html#

Back to the top