Are "things" other than Services attachable to other Services ?   I think so, but if this the case, it doesn't change the fact that the other "thing" should at some point be connected to another service.

Currently we understand attaching services this way :

Mouth <----attaches---> Ear

But I think this is valid too :

Joystick <-- attaches with Axis ---> Motor

The notation would be :

motor.attach(joystick.getAxis("x"))

getAxis would return an Axis which would implement AnalogControl BUT in order to attach consistently with the possibility of remote services attaching in this way the joysticks name must be exchanged.  Since AnalogControl is the thing shared when attaching, the AnalalogControl must extend the NameProvider interface, which provides ... you got it 

getName()

The same concept applied to Pin attaching

motor.attach(controller.getPin(3))

getPin returns a PinDefinition which "must" be able to provide NameProvider.getName() .. 
PinDefinition already has a getName() which returns the name of the Pin ("A0", "D1" .. etc.) .. this should be changed to getPinName()
PinDefinition.getName() (since it comes from NameProvider) must return the originating service name ..

If you use NameProvider - the "expected" return of getName() is the service's name - this can't be mandated by code, but has to be agreed apon by convention.

Thoughts ? 

kwatters

7 years 1 month ago

I think I see where you're going with this.  There needs to be a way to route the data between the buttons and the motor controller.  I think that's the motivation.. and currently we only really route data between services.

I think we can/should treat Arduino.MrlDevices the same way we treat Joystick.Button/Axis  

So, if the attachable interface has a pointer to it's host, we could do something like this.  Basically, if you're passing an axis to the motor controller, the motor controller needs to know which service provided the button.

This should probably be the same as an arduino with a digital input pin, because fundamentally that's the same thing as a button in most ways.

So, I guess, rather than turning these buttons/devices into services of their own, we could include in the interface a reference to their "host" service.  So, maybe devices have host services.  And we could have a naming convention that any device must have a name and a reference to it's host ?  

I'm not sure what the best approach is here, but I think the approach should attempt to normalize buttons,axis,devices to all be the same.   In a previous life, i think this was all just SensorData ...

 

Right its about the "setup" of routing.  The only reference needed is a service name.  The service name is a unique identifier and the simplest part of a service in order to setup a pub/sub.

The data itself that runs over the route doesn't need to supply the name but the thing which creates the route does.  

PinDefinition needs to supply the service name, PinData does not.

Locally, I've started implementing this. 
PinDefinition had a .getName() it was the name of the pin (A0 D7 etc), I've changed this to getPinName to avoid the collision and made it implement the NameProvider interface.  Now its getName() will return the service name from which it belongs to.