Re: [ecf-dev] pi4j and OSGi (remote) services

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

On 7/4/2014 12:17 PM, Wim Jongman wrote:

       // 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:

There is really only one GPIO so I guess the singleton is a requirement. I guess there is some synchronization going and that all services must share the same controller.

My gut feeling says to make a GPIOControllerService that performs operations directly on the Pin instead of passing Pin instances around. At first glance the Pin instances seem overkill and will complicate the service structure.

Perhaps you are right, but my concern about putting everything on a GPIOControllerService could result in a complex API...for example it might require quite a few methods for simply controlling a single pin (e.g. in the pi4j example [1]).

One thought I've had:   What if there was a local only (not exported/remoted) GPIOControllerService, and as part of this service multiple pin-specific services were automatically create/provisioned, registered and then exported as remote services, with service properties/meta-data that identified the pin (pin #5) and associated a name with the physical pin (e.g. 'lightbulb').   Then clients could specify desired/required values for these pin identifiers in the (remote) service OSGi filter...e.g.

($(('pin.id'==5)("pin.name"=="lightbulb"))

via DS or others.

Then the pin-specific service interface could be something very simple, like:

public IGPIOPin {

public Boolean toggle();
public Boolean getToggleState();

}

Or something similar.  

I don't know for sure whether this would work (haven't thought it through) but it might be a nice approach for OSGi services, and remote services.

Scott

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