Difference between revisions of "Input/output API revamp"

Latest revision as of 00:48, 10 May 2013

Not all parts of the input and output APIs have clearly defined documentation, for example regarding memory allocation.
Neither API exposes the parameters they can take, let alone any meta-information about them.
Some of the output modules are still stuck on the very old API, which limits their usefulness.
The lack of a well-thought out API for these is holding back the spinoff of these into libsigrokfile, which could be a very interesting project itself.

Clearly, we'll want to stick with what we've done for drivers where exposing parameters is concerned. That means:
- An enum list like SR_CONF_* for the options, though not SR_CONF itself, as this would stop it from spinning off from libsigrok.
- A meta structure like sr_config_info to expose short and long names and descriptions for all the keys.
- GVariant as the mechanism to pass strongly typed values back and forth.

@@ Line 5: / Line 5: @@
 * Some of the output modules are still stuck on the very old API, which limits their usefulness.
 * The lack of a well-thought out API for these is holding back the spinoff of these into libsigrokfile, which could be a very interesting project itself.
+== Ideas ==
+* Clearly, we'll want to stick with what we've done for drivers where  exposing parameters is concerned. That means:
+** An enum list like SR_CONF_* for the options, though not SR_CONF itself, as this would stop it from spinning off from libsigrok.
+** A meta structure like sr_config_info to expose short and long names and descriptions for all the keys.
+** GVariant as the mechanism to pass strongly typed values back and forth.