Hi Mats,

its great when you just suggested several things I've implemented locally :D
It means were thinking along the same lines...

package org.myrobotlab.service.interfaces;
public interface RangingControl extends DeviceControl {
public void startRanging();   
public void stopRanging();   
public void setUnitCm();   
public void setUnitInches();
}
package org.myrobotlab.service.interfaces;
public interface RangeListener {     
public void onRange(Double range); 
}

package org.myrobotlab.service.interfaces;
public interface RangePublisher {   
Double publishRange(Double range); 
}

"Imho the users should have the freedom to connect services together freely."

I completely agree .. 

In fact this is related to the Attach post (http://myrobotlab.org/content/attach-pattern) and the idea that there should be a default behavior, and the user should be able to attach one service to another with the minimal amount of complexity (without blocking the ability to access more complexity)

The peer utilities were a means to do this with 'configuration' vs code..   Because in many instances the user doesn't have access to code, but may have access to configuration.  I don't know if what I've done with peers & MRL DNA - (http://myrobotlab.org/content/sample-inmoov-head-dna  / http://myrobotlab.org/content/services-remix )   But, the general idea was to creat config which could change names & types "easily" for the user.   I don't think a lot of the users know that its there or understand it fully.

Each service is supposed to have a "default' config for itself and the peers it references.. This is the stuff you see in getMetaData..

meta.addPeer("torso", "InMoovTorso", "torso");

In complex services - there might be shared resources - and you use 'sharing' to basically create the same name at two points in the configuration

meta.sharePeer("head.arduino", "left", "Arduino", "shared left arduino");

And as you were referring to earlier - "type" - in the case "Arduino" is just a string value, so it could be changed to any type which satisfied the peer's interface.

I like to imagine the future where you could query MRL with a HTTP request - get a large DNA definition (I think this can be done now) .. modify it - and post it back, and the workflow could give you access and control over all peer defintions - both of names, sharing, and typed resources

In the code snippet above, I don't understand how the Pingdar service knows that it should use the virtualArduino and not a real Arduino.

If I uncomment the 

virtual.connect("COM5")

The virtual arduino will hijack the COM5 port, and anything connecting to COM5 will really connect to the VirtualArduino regardless if the hardware port actually exists..

hence, commented out == connect to the real COM5
uncommented == connect to the virtual arduino