Scopes refactoring

Usually august is a good time to think on refactorings. During the year normal operation there is never enough time to look back. The sentence "I want all, and I want it now" it's a classical sentence from clients and bosses (many times followed with a "I want it fix, but don't touch any thing").

Also is good because too many managers doesn't care about refactoring. They don't really understand what this means and didn't give to it the real value of this action. For them, often, the maintenance of some code is sort of magic, they don't know how this can be made. Furthermore they don't care, and only think in do it fast an cheap.

In the case of the scope, we are currently using the scope waveforms in a Filling Pattern calculation using the Fast Current Transformer signal. This was the fpFCT project. In this case, we went far away from the original design of the access to the scopes. This original design was already improved long a go, and looks that now it's time to remade it base on the newer requirements.

The current bottleneck is the Visa middlemen. The agent that shows the user the interface of an instrument like an scope doesn't know about protocols. This agent knows the language to talk with the instrument, but not the channel used to have bidirectional communication with it.

From Max IV, there is a proposal to talk directly via socket. This will remove from the scene one of the actors, and for sure will improve.

The second proposal, should be helped by a new feature requested in tango: give the information to the device that someone is listening (or not) over the events on an attribute. This is, avoid to request information to the instrument if noone is listening.

Current idea of the refactoring is to use proposal one, and by commands (until the mentioned feature is available) configure the attributes that are being updated by an isolated thread, optimizing the scope access, in an approach to proposal two.

Update 20130806: Max IV has contributed with their nice idea in a branch.