Using protocols to standardize communications.

[MatthieuDartiailh]

This point was evoked by @p3trus as a way to avoid code duplication. I am not sure what we should do about it.
With the current system we could quite easily consider having a protocol kwarg for features which would be used for default getting, setting and operation setting behavior, which would allow to have multiple protocols by instruments.If a bunch of feature need the same get/set customization we could abstract it in a protocol. The question is would it truly make things easier ? Should it be limited to Feature or also include Actions ?
I am interested in any opinion on this one.

[hgrecco]

If I understood @p3trus correctly the protocol is a syntax to define messages exchanged with instruments. For example, you could define a and then tell later what the separator is (for example a space). The only time that I have seen such a need is to define end of messages and this is handled by lower-level libraries.

My feeling is that this is another indirection that we do not really need.

[MatthieuDartiailh]

Actually we could use it to have two different standard get/set because the instrument use two kinds of message formatting/handling. My idea of a protocol would be something defining the get/set/check_operation behaviour in any way we need so that we can group things rather than copy paste custom getters and setters.

[hgrecco]

Wouldn't this extra indirection cause more trouble than benefit?

[MatthieuDartiailh]

Not sure, maybe. @p3trus would you mind arguing again a bit for protocols ?

[p3trus]

If you simply send a message and read until a delimiter there is not a huge benefit. But if you have more complex protocols you start repeating functionallity all over the place. E.g. binary protocols, protocols echoing parts of the message or protocols requiring CRC values calculated from the message.

[MatthieuDartiailh]

@p3trus could you point us to a case in slave where using protocols did make things easier ? Also have you ever considered having multiple protocols in a single driver and using them for different commands ?

[crazyfermions]

@p3trus , please explain how this would affect lantz in general and not just the actual implementation of a specific driver? If you have a binary protocol which is used by a specific family of instruments (e.g. a specific manufacturer), you would just use the byte-based communication which lantz offers, implement the protocol in a basic driver and avoid the code duplication by inheritance. I think lantz should not offer such binary protocols by itself (unless they are standard like usbtmc).