Hi Peter,
Am 26.10.2016 um 21:09 schrieb Peter Stuge <[email protected]>:
> Matthias Heidbrink wrote:
>> In many standard APIs from very different areas I have seen have
>> functionality to pass proprietary commands to devices.
>
> The problem is that you trade standardization for flexibility, and
> the result of that is inevitably divergence in quality when no single
> stakeholder is responsible for the software as a whole.
Actually we have this problem in libsigrok anyway because only the posessor of
a device can test it and Uwe or biot don’t have all devices supported by
sigrok, so they cannot test if changes to drivers don’t break anything.
My suggestion would attenuate this problem because more new features can be
implemented without touching existing drivers.
> [email protected] wrote:
>> Anyway I think you make a good case for this. Anyone agree/disagree
>
> The arguments for bypassing standardization look appealing at first,
> but in the long run I do not feel that they are worth their cost.
I see it like this:
If you have an exotic feature on your device, it would be unnecessary ballast
to implement a generic way to support this feature. The additional effort to
build in generic support through all of libsigrok and possibly further libs and
applications will also often keep people off implementing support for features
that are not absolutely mandatory, but would just be nice to have. At least it
does for me. And there could be features where the standard semantics of
libsigrok might not work. Therefore I believe it to be feasible to have a way
to pass user-specific parameters to a device. The way suggested by me
(name-value pairs) also allows using descriptive names.
I’ll give you an example of what I mean: The Norma DM950 multimeter (Norma
DM9x0 series) needs a special setup program that allows setting the owner's
name, date and time for the built-in clock and a lot of other low-level
device-specific flags and parameters, e.g. type of current clamp. I did not
implement support for all of this when I wrote the sigrok driver because it
would have been just too messy to implement all of them as new features in
sigrok, and most probably Uwe and biot would not like me to do it because this
stuff is too far away from the core functionality of sigrok. I remotely
remember having had an IRC discussion with biot on that a longer time ago. The
manufacturer’s setup program is an old DOS program that won’t run on a modern
computer. I would love to implement these features inside of the sigrok driver
and sigrok-cli to be sure that I will still be able to make full use of this
device in a few years from now, but I think I can really only think of doing
this in form of device-specific commands.
A similar problem exists for the Gossen Metrawatt Metrahit 2x and Starline
Series devices.
When you learn that a second or third device exists that has the same feature
as the one you’re planning to implement, you can still decide to go for a
generic feature and adopt the existing drivers, of course.
Bye, Matthias
------------------------------------------------------------------------------
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive.
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
_______________________________________________
sigrok-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
