A case for Actor capability descriptions

[bilderbuchi]

I think it would be important to require an Actor to be able to describe the capabilities of its Driver (e.g. list of Parameters and Actions) in an automated fashion, e.g. via a schema exchange mechanism.
So far, this was one of the points that made Avro attractive (as this is built into that protocol), but Avro is considered to complex for preserving a low entry threshold (#43).
However, this is not tied to using Avro, and can be implemented in a number of other ways.

There is significant disagreement on the benefits/drawbacks of requiring this description (see #43).
I'll try to make a case for requiring that Actors be able to describe their capabilities in an automated fashion, and will try to support this with use cases, usage scenarios, maybe some prototyping (e.g. how to derive a schema from any pymeasure Instrument -- I already did that before).

[BenediktBurger]

Shouldn't we also standardize the pymeasure docstrings in order to make at least pymeasure compatible (and here at least new instruments)?

[bilderbuchi]

Shouldn't we also standardize the pymeasure docstrings in order to make at least pymeasure compatible (and here at least new instruments)?

Yes we should.

[BenediktBurger]

I wrote a "TransparentDirector", which requests at access all properties from the connected Actor, such that you could replace inst = SomeInstrument(adapter) with inst = TransparentDirector(actor="Namespace.Actor_of_SomeInstrument") and your code will work the same, as long as you use properties (get or set).

A capability description would allow that director to also call methods transparently (right now you have to add a Descriptor for each method you'd like to use) and to use channels transparently.
Last but not least, the description would allow to use autocompletion on the TransparentDirector.

[bilderbuchi]

Nice!
One thing a generic capability description feature in LECO would enable is to have this be independent of the instrument library that is behind the Actor. If the instrument library is consistent enough, this would have to be implemented once for all its instruments.
E.g. in pymeasure, we heavily use properties, so it's pretty straightforward to detect the interfaces. Other libraries might use methods only, or maybe consistenly named GetX/SetX pairs (thinking of C++ idioms).